> I could see that allocating out of the slab would mean less waste when
> you have >4k pages, but why would it be faster than just allocating a
> page directly?
The slab allocator is far more optimized than the page allocator
for the fast path (in fact page could need some major diet in its fast
On Sat, 8 Sep 2012 05:08:50 +0200
Andi Kleen wrote:
> On Fri, Sep 07, 2012 at 08:54:18PM -0400, Jeff Layton wrote:
> > On Fri, 07 Sep 2012 14:26:56 -0700
> > Andi Kleen wrote:
> >
> > > Jeff Layton writes:
> > >
> > > > This patchset is a first pass at overhauling the getname/putname
> > > >
On Fri, Sep 07, 2012 at 08:54:18PM -0400, Jeff Layton wrote:
> On Fri, 07 Sep 2012 14:26:56 -0700
> Andi Kleen wrote:
>
> > Jeff Layton writes:
> >
> > > This patchset is a first pass at overhauling the getname/putname
> > > interface to use a struct. The idea here is to add a new getname_info
On Fri, 07 Sep 2012 14:26:56 -0700
Andi Kleen wrote:
> Jeff Layton writes:
>
> > This patchset is a first pass at overhauling the getname/putname
> > interface to use a struct. The idea here is to add a new getname_info
> > struct that allow us to pass around some auxillary info along with
> >
Jeff Layton writes:
> This patchset is a first pass at overhauling the getname/putname
> interface to use a struct. The idea here is to add a new getname_info
> struct that allow us to pass around some auxillary info along with
> the string that getname() returns.
Couldn't you just use some of t
This patchset is a first pass at overhauling the getname/putname
interface to use a struct. The idea here is to add a new getname_info
struct that allow us to pass around some auxillary info along with
the string that getname() returns.
This allows us to do some interesting things:
- no need to w
6 matches
Mail list logo
