Re: [PATCH] cacheline align pagevec structure

[William Lee Irwin III]

Marcelo Tosatti <marcelo.tosatti@xxxxxxxxxxxx> wrote:
>> I do not see a problem with changing pagevec to "15" page pointers either, 
>> Andrew, is there a special reason for that "16"? Is intentional to align
>> to 64 kbytes (IO device alignment)? I dont think that matters much because
>> of the elevator which sorts and merges requests anyway?

On Thu, Sep 09, 2004 at 03:52:26PM -0700, Andrew Morton wrote:
> No, it was just a randomly-chosen batching factor.
> The tradeoff here is between
> a) lock acquisition frequency versus lock hold time (increasing the size
>    helps).
> b) icache misses versus dcache misses. (increasing the size probably hurts).
> I suspect that some benefit would be seen from making the size very small
> (say, 4). And on some machines, making it larger might help.

Reducing arrival rates by an Omega(NR_CPUS) factor would probably help,
though that may blow the stack on e.g. larger Altixen. Perhaps
O(lg(NR_CPUS)), e.g. NR_CPUS > 1 ? 4*lg(NR_CPUS) : 4 etc., will suffice,
though we may have debates about how to evaluate lg(n) at compile-time...
Would be nice if calls to sufficiently simple __attribute__((pure))
functions with constant args were considered constant expressions by gcc.

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