lkml.org 
[lkml]   [2002]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.4.19pre2aa1
    On Tue, Mar 12, 2002 at 07:46:51AM -0300, Rik van Riel wrote:
    > On Tue, 12 Mar 2002, Andrea Arcangeli wrote:
    >
    > > If you assume a pure random input, I don't see how can you distribute it
    > > better with a simple mul assembler instruction. That's my whole point.
    >
    > Since you've just given two examples of common non-random
    > workloads yourself, I don't see how you can reasonably
    > expect a pure random input.

    It is not pure random of course, it can't be pure random there will be
    always some influence for example from the I/O patterns, in particular
    right after boot, but the randomness of the input is still excellent,
    it's not an inode pointer that could have a very little change. I made
    the example to say in the so unlikely case it happens, that's great,
    we'll have the guarantee that those two pages won't collide in the same
    waitqueue.

    Infact above I said "If you _assume_ pure random input". That's what I'm
    interested about, if you _assume_ pure random input (in practice there
    will always be some infuence).

    Bill said that "randomness" is not the right word to use, I instead
    think it's the key. If it's pure random mul will make no difference to
    the distribution. And the closer we're to pure random like in the
    wait_table hash, the less mul will help and the more important will be
    to just get right the two contigous pages in the same cacheline and
    nothing else.

    For the pagecache hash the thing is different, as said with the
    pagecache some patological workload can really generate lots of
    collisions reproducibly, big patterns can happen there, for example if
    the inode happens to be allocated in a row right after boot, and then
    some massive I/O starts on similar patterns. While in the
    developer-workloads with lots of small files and VM activity, the
    pagecache hash should be just good.

    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/

    \
     
     \ /
      Last update: 2005-03-22 13:24    [W:0.035 / U:59.480 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site