Messages in this thread | | | Date | Thu, 9 Sep 2004 19:12:38 -0300 | From | Marcelo Tosatti <> | Subject | Re: [PATCH] cacheline align pagevec structure |
| |
On Thu, Sep 09, 2004 at 04:09:05PM -0700, William Lee Irwin III wrote: > Marcelo Tosatti <marcelo.tosatti@cyclades.com> 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.
Let me see if I get you right - basically what you're suggesting is to depend PAGEVEC_SIZE on NR_CPUS? - 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/
| |