public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: linux-kernel@vger.kernel.org
Cc: akpm@zip.com.au
Subject: Re: hashed waitqueues
Date: Fri, 4 Jan 2002 15:48:13 -0800	[thread overview]
Message-ID: <20020104154813.A10391@holomorphy.com> (raw)
In-Reply-To: <20020104094049.A10326@holomorphy.com> <3C3635A8.447EE52E@zip.com.au>
In-Reply-To: <3C3635A8.447EE52E@zip.com.au>; from akpm@zip.com.au on Fri, Jan 04, 2002 at 03:07:20PM -0800

William Lee Irwin III wrote:
+       /*
+        * Although the default semantics of wake_up() are
+        * to wake all, here the specific function is used
+        * to make it even more explicit that a number of
+        * pages are being waited on here.
+        */
+       if(waitqueue_active(page_waitqueue(page)))
+               wake_up_all(page_waitqueue(page));

On Fri, Jan 04, 2002 at 03:07:20PM -0800, Andrew Morton wrote:
> Does the compiler CSE these two calls to page_waitqueue()?
> All versions?   I'd be inclined to do CSE-by-hand here.

I'm not sure if CSE is run before or after inlining, but it
is probably not wise to leave it up to the compiler.

On Fri, Jan 04, 2002 at 03:07:20PM -0800, Andrew Morton wrote:
> Also, why wake_up_all()?  That will wake all tasks which are sleeping
> in __lock_page(), even though they've asked for exclusive wakeup
> semantics.  Will a bare wake_up() here not suffice?

A couple of other private responses pointed this out, and also had
suggestions for several ways to avoid the thundering herds. I am not
sure it's possible to honor exclusive wakeup requests here without
creating problems or otherwise having to propagate semantic changes
further up the call chain. I think that comment and one of the others
needs to be expanded to make the exclusive wakeup issue clearer.

Also there is a bug in the hash function (pointed out by an anonymous
private response):


On Fri, Jan 04, 2002 at 07:16:33PM -0000, an anonymous person told me:
> One *bug* in your code is that if toy have 64-bit longs, your
> GOLDEN_RATIO_PRIME isn't large enough and page_waitqueue will
> always compute hash = 0.
> The closest primes to phi * 2^64 = 11400714819323198485.95... are:
>	...
>	11400714819323198333    
>	11400714819323198389
>	11400714819323198393
>	*
>	11400714819323198549
>	11400714819323198581
>	11400714819323198647
>	...

which is easy enough to repair with a conditional definition of
GOLDEN_RATIO_PRIME.

The same person also mentioned that less work could be done in
the hash function by storing the shift amount directly in the zone,
and also pointed out that the masking operation is unnecessary as the
shift already annihilates the high-order bits.

Cheers,
Bill

  parent reply	other threads:[~2002-01-04 23:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-04 17:40 hashed waitqueues William Lee Irwin III
2002-01-04 21:47 ` Momchil Velikov
2002-01-04 23:07 ` Andrew Morton
2002-01-04 23:21   ` Andrew Morton
2002-01-04 23:48   ` William Lee Irwin III [this message]
2002-01-05  0:37 ` Daniel Phillips
2002-01-05  1:39   ` William Lee Irwin III
2002-01-05  2:44     ` Daniel Phillips
2002-01-05  5:06       ` William Lee Irwin III
2002-01-08 18:20         ` William Lee Irwin III
2002-01-08 18:27           ` William Lee Irwin III
     [not found]             ` <523d1gu1ni.fsf@love-boat.topspincom.com>
2002-01-08 18:44               ` William Lee Irwin III
2002-01-08 19:20           ` Hugh Dickins
2002-01-08 20:19             ` William Lee Irwin III
2002-01-16 14:21     ` Jamie Lokier
2002-01-16 17:42       ` William Lee Irwin III
2002-01-18  0:34         ` Jamie Lokier
2002-01-06 21:09 ` Rik van Riel
  -- strict thread matches above, loose matches on Subject: below --
2002-01-04 21:17 Ed Tomlinson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020104154813.A10391@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox