Le samedi 12 mai 2007 à 20:24 +0100, Mel Gorman a écrit :
> On (12/05/07 20:58), Nicolas Mailhot didst pronounce:
> > Le samedi 12 mai 2007 à 20:09 +0200, Nicolas Mailhot a écrit :
> > > Le samedi 12 mai 2007 à 17:42 +0100, Mel Gorman a écrit :
> > >
> > > > order-2 (at least 19 pages but more are
On (12/05/07 20:58), Nicolas Mailhot didst pronounce:
> Le samedi 12 mai 2007 à 20:09 +0200, Nicolas Mailhot a écrit :
> > Le samedi 12 mai 2007 à 17:42 +0100, Mel Gorman a écrit :
> >
> > > order-2 (at least 19 pages but more are there) and higher pages were free
> > > and this was a NORMAL alloc
Le samedi 12 mai 2007 à 17:42 +0100, Mel Gorman a écrit :
> order-2 (at least 19 pages but more are there) and higher pages were free
> and this was a NORMAL allocation. It should also be above watermarks so
> something screwy is happening
>
> *peers suspiciously*
>
> Can you try the following p
On (12/05/07 10:11), Nicolas Mailhot didst pronounce:
> Le vendredi 11 mai 2007 à 21:36 +0100, Mel Gorman a écrit :
>
> > I'm pretty sure I have. I recreated the tree and reverted the same patch as
> > you and regenerated the diff below. I sent it to myself and it appeared ok
> > and another autom
On (11/05/07 20:30), Nicolas Mailhot didst pronounce:
> Le vendredi 11 mai 2007 à 19:45 +0200, Nicolas Mailhot a écrit :
> > Le vendredi 11 mai 2007 à 18:38 +0100, Mel Gorman a écrit :
>
> > > so I'd like to look at the
> > > alternative option with kswapd as well. Could you put that patch back in
Le vendredi 11 mai 2007 à 19:45 +0200, Nicolas Mailhot a écrit :
> Le vendredi 11 mai 2007 à 18:38 +0100, Mel Gorman a écrit :
> > so I'd like to look at the
> > alternative option with kswapd as well. Could you put that patch back in
> > again
> > please and try the following patch instead?
>
On Fri, 11 May 2007, Mel Gorman wrote:
> Excellent. I am somewhat suprised by the result so I'd like to look at the
> alternative option with kswapd as well. Could you put that patch back in again
> please and try the following patch instead? The patch causes kswapd to reclaim
> at higher orders i
Le vendredi 11 mai 2007 à 18:38 +0100, Mel Gorman a écrit :
> On (11/05/07 13:51), Nicolas Mailhot didst pronounce:
> > Le vendredi 11 mai 2007 à 10:08 +0100, Mel Gorman a écrit :
> >
> > > > seems to have cured the system so far (need to charge it a bit longer to
> > > > be sure)
> > > >
> > >
On (11/05/07 13:51), Nicolas Mailhot didst pronounce:
> Le vendredi 11 mai 2007 à 10:08 +0100, Mel Gorman a écrit :
>
> > > seems to have cured the system so far (need to charge it a bit longer to
> > > be sure)
> > >
> >
> > The longer it runs the better, particularly under load and after
> > u
Le vendredi 11 mai 2007 à 10:08 +0100, Mel Gorman a écrit :
> > seems to have cured the system so far (need to charge it a bit longer to
> > be sure)
> >
>
> The longer it runs the better, particularly under load and after
> updatedb has run. Thanks a lot for testing
After a few hours of load t
On (11/05/07 07:56), Nicolas Mailhot didst pronounce:
> Le jeudi 10 mai 2007 à 16:01 -0700, Christoph Lameter a écrit :
> > On Fri, 11 May 2007, Mel Gorman wrote:
> >
> > > Nicholas, could you backout the patch
> > > dont-group-high-order-atomic-allocations.patch and test again please?
> > > The f
Le jeudi 10 mai 2007 à 16:01 -0700, Christoph Lameter a écrit :
> On Fri, 11 May 2007, Mel Gorman wrote:
>
> > Nicholas, could you backout the patch
> > dont-group-high-order-atomic-allocations.patch and test again please?
> > The following patch has the same effect. Thanks
>
> Great! Thanks.
Th
On (10/05/07 15:49), Christoph Lameter didst pronounce:
> On Thu, 10 May 2007, Mel Gorman wrote:
>
> > > I cannot predict how allocations on a slab will be performed. In order
> > > to avoid the higher order allocations in we would have to add a flag
> > > that tells SLUB at slab creation creati
On Fri, 11 May 2007, Mel Gorman wrote:
> Nicholas, could you backout the patch
> dont-group-high-order-atomic-allocations.patch and test again please?
> The following patch has the same effect. Thanks
Great! Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Thu, 10 May 2007, Mel Gorman wrote:
> > I cannot predict how allocations on a slab will be performed. In order
> > to avoid the higher order allocations in we would have to add a flag
> > that tells SLUB at slab creation creation time that this cache will be
> > used for atomic allocs and th
On (10/05/07 15:27), Christoph Lameter didst pronounce:
> On Thu, 10 May 2007, Mel Gorman wrote:
>
> > On (10/05/07 15:11), Christoph Lameter didst pronounce:
> > > On Thu, 10 May 2007, Mel Gorman wrote:
> > >
> > > > I see the gfpmask was 0x84020. That doesn't look like __GFP_WAIT was
> > > > s
On (10/05/07 14:49), Christoph Lameter didst pronounce:
> On Thu, 10 May 2007, Andrew Morton wrote:
>
> > Christoph, can we please take a look at /proc/slabinfo and its slub
> > equivalent (I forget what that is?) and review any and all changes to the
> > underlying allocation size for each cache?
On Thu, 10 May 2007, Mel Gorman wrote:
> On (10/05/07 15:11), Christoph Lameter didst pronounce:
> > On Thu, 10 May 2007, Mel Gorman wrote:
> >
> > > I see the gfpmask was 0x84020. That doesn't look like __GFP_WAIT was set,
> > > right? Does that mean that SLUB is trying to allocate pages atomica
On (10/05/07 15:11), Christoph Lameter didst pronounce:
> On Thu, 10 May 2007, Mel Gorman wrote:
>
> > I see the gfpmask was 0x84020. That doesn't look like __GFP_WAIT was set,
> > right? Does that mean that SLUB is trying to allocate pages atomically? If
> > so,
> > it would explain why this sit
On Thu, 10 May 2007, Mel Gorman wrote:
> I see the gfpmask was 0x84020. That doesn't look like __GFP_WAIT was set,
> right? Does that mean that SLUB is trying to allocate pages atomically? If so,
> it would explain why this situation could still occur even though high-order
> allocations that coul
On Thu, 10 May 2007, Andrew Morton wrote:
> Christoph, can we please take a look at /proc/slabinfo and its slub
> equivalent (I forget what that is?) and review any and all changes to the
> underlying allocation size for each cache?
>
> Because this is *not* something we should change lightly.
I
On Thu, 10 May 2007 14:28:18 -0700
[EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8464
>
>Summary: autoreconf: page allocation failure. order:2,
> mode:0x84020
> Kernel Version: 2.6.21-mm2 with SLUB
> Status: NEW
> S
22 matches
Mail list logo
