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
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 there) and
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
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
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
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 automated
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 patch
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 allocation. It
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
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
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
> >
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
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
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 following
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 testing
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
updatedb has run.
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)
The longer it
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 if
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?
I'll try
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 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.
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
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
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
> > > >
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
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
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
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
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.
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
>
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
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.
It
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 could
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 situation
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 atomically?
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 (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
set,
right?
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 thus we
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 creation time
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 body
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.
The
44 matches
Mail list logo
