[lkml]   [2005]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Processes stuck on D state on Dual Opteron
Nick Piggin wrote:
> Nick Piggin wrote:
>> Chen, Kenneth W wrote:
>>> I like the patch a lot and already did bench it on our db setup.
>>> However,
>>> I'm seeing a negative regression compare to a very very crappy patch
>>> (see
>>> attached, you can laugh at me for doing things like that :-).
>> OK - if we go that way, perhaps the following patch may be the
>> way to do it.
> Here.

Actually yes this is good I think.

What I was worried about is that you could lose some fairness due
to not being put on the queue before allocation.

This is probably a silly thing to worry about, because up until
that point things aren't really deterministic anyway (and before this
patchset it would try doing a GFP_ATOMIC allocation first anyway).

However after the subsequent locking rework, both these get_request()
calls will be performed under the same lock - giving you the same
fairness. So it is nothing to worry about anyway!

It is a bit subtle: get_request may only drop the lock and return NULL
(after retaking the lock), if we fail on a memory allocation. If we
just fail due to unavailable queue slots, then the lock is never
dropped. And the mem allocation can't fail because it is a mempool
alloc with GFP_NOIO.


SUSE Labs, Novell Inc.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-12 14:25    [W:0.058 / U:0.020 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site