On Mon, Feb 02, 2009 at 11:50:17PM -0800, David Miller wrote:

quoted text
> From: Jarek Poplawski

> Date: Mon, 2 Feb 2009 08:43:58 +0000

>

> > On Mon, Feb 02, 2009 at 12:18:54AM -0800, David Miller wrote:

> > > Allocating 4096 or 8192 bytes for a 1500 byte frame is wasteful.

> >

> > I mean allocating chunks of cached pages similarly to sk_sndmsg_page

> > way. I guess the similar problem is to be worked out in any case. But

> > it seems doing it on the linear area requires less changes in other

> > places.

>

> This is a very interesting idea, but it has some drawbacks:

>

> 1) Just like any other allocator we'll need to find a way to

>    handle > PAGE_SIZE allocations, and thus add handling for

>    compound pages etc.

>

>    And exactly the drivers that want such huge SKB data areas

>    on receive should be converted to use scatter gather page

>    vectors in order to avoid multi-order pages and thus strains

>    on the page allocator.

I guess compound pages are handled by put_page() enough, but I don't

think they should be main argument here, and I agree: scatter gather

should be used where possible.
>

quoted text
> 2) Space wastage and poor packing can be an issue.

>

>    Even with SLAB/SLUB we get poor packing, look at Evegeniy's

>    graphs that he made when writing his NTA patches.

I'm a bit lost here: could you "remind" the way page space would be

used/saved in your paged variant e.g. for ~1500B skbs?
>

quoted text
> Now, when choosing a way to move forward, I'm willing to accept a

> little bit of the issues in #2 for the sake of avoiding the

> issues in #1 above.

>

> Jarek, note that we can just keep your current splice() copy hacks in

> there.  And as a result we can have an easier to handle migration

> path.  We just do the page RX allocation conversions in the drivers

> where performance really matters, for hardware a lot of people have.

>

> That's a lot smoother and has less issues that converting the system

> wide SKB allocator upside down.

> 

Yes, this looks reasonable. On the other hand, I think it would be

nice to get some opinions of slab folks (incl. Evgeniy) on the expected

efficiency of such a solution. (It seems releasing with put_page() will

always have some cost with delayed reusing and/or waste of space.)
Jarek P.

--

To unsubscribe from this list: send the line "unsubscribe netdev" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html