Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S310608AbSCHAXo>; Thu, 7 Mar 2002 19:23:44 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S310611AbSCHAXg>; Thu, 7 Mar 2002 19:23:36 -0500
Received: from penguin.e-mind.com ([195.223.140.120]:23829 "EHLO
	penguin.e-mind.com") by vger.kernel.org with ESMTP
	id <S310608AbSCHAXV>; Thu, 7 Mar 2002 19:23:21 -0500
Date: Fri, 8 Mar 2002 01:22:39 +0100
From: Andrea Arcangeli <andrea@suse.de>
To: "Richard B. Johnson" <root@chaos.analogic.com>
Cc: William Lee Irwin III <wli@holomorphy.com>, linux-kernel@vger.kernel.org,
        riel@surriel.com, hch@infradead.org, phillips@bonn-fries.net
Subject: Re: 2.4.19pre2aa1
Message-ID: <20020308012239.B1356@dualathlon.random>
In-Reply-To: <20020307201819.GF786@holomorphy.com> <Pine.LNX.3.95.1020307152948.22256A-100000@chaos.analogic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.3.95.1020307152948.22256A-100000@chaos.analogic.com>
User-Agent: Mutt/1.3.22.1i
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Mar 07, 2002 at 03:38:09PM -0500, Richard B. Johnson wrote:
> On Thu, 7 Mar 2002, William Lee Irwin III wrote:
> 
> > On Thu, Mar 07, 2002 at 06:03:00PM +0100, Andrea Arcangeli wrote:
> > > For the other points I think you shouldn't really complain (both at
> > > runtime and in code style as well, please see how clean it is with the
> > > wait_table_t thing), I made a definitive improvement to your code, the
> > > only not obvious part is the hashfn but I really cannot see yours
> > > beating mine because of the total random input, infact it could be the
> > > other way around due the fact if something there's the probability the
> > > pages are physically consecutive and I take care of that fine.
> > 
> > 
> > I don't know whose definition of clean code this is:
> > 
> > +static inline wait_queue_head_t * wait_table_hashfn(struct page * page, wait_table_t * wait_table)
> > +{
> > +#define i (((unsigned long) page)/(sizeof(struct page) & ~ (sizeof(struct page) - 1)))
> > +#define s(x) ((x)+((x)>>wait_table->shift))
> > +	return wait_table->head + (s(i) & (wait_table->size-1));
> > +#undef i
> > +#undef s
> > +}
> > 
> > 
> > I'm not sure I want to find out.
> > 
> > 
> > Bill
> 
> Methinks there is entirely too much white-space in the code. It
> is almost readable *;). It probably could be fixed up to slip through
> the compiler with no possibility of human interpretation, but that would
> take a bit more work ;^)

well, to me it is very readable, but I'm certainly biased I admit.

You have to think it this way:

-	"i" is the random not predictable input
-	"i" is generated by dropping the non random bits of the "page"
		with a cute trick that drops the bit with
		a shiftright with an immediate argument, it's not a
		division so it's faster it could been
		"page/sizeof(struct page)" but it would been slower
-	s(i) takes into account not just the last "wait_table->shift" bytes
	of the random information in "i", but also the next "shift"
	bytes, so it's more random even if some of those lower or higher
	bits is generating patterns for whatever reason
-	finally you mask out the resulting random information s(i) with
	size-1, so you fit into the wait_table->head memory.

The result is that it exploits most of the random input, and physically
consecutive pages are liekly to use the same cacheline in case there is
some pattern. That looks a good algorithm to me.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/