[lkml]   [1999]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] hashtable sizes for icache and dcache
    On Wed, 22 Sep 1999 wrote:

    >considered an acceptable fix, even for the short term. Fix the problem,
    >not the symptoms.

    You are wrong. I fixed the _cause_. My fix was a compile time thing so to
    make it working everywhere you should add a kernel option to set the new
    value or the old value. We all want it autotuning of course so it was a
    missing feature but the fix was correct.

    To fix the _same_ cause in a dynamic way I should have changed my focus on
    a differen work, in a differen tree-branch and doing a controversial patch
    and so I choosed the compile time way since I only wanted to fix the
    problem on the class of machine I use (>=32mbyte of ram).

    I am very happy to get the dynamic fix too of course and that's why I
    CC'ed to Chuck as I was almost sure he worked on something like that.

    Now it cames out that the icache is static for everybody out there (unless
    Chuck did that), so I can do the icache dynamic thing of course, but in
    the meantime I'll __need__ to use the compile time fix to have a chance to
    test my code.

    andrea@laser:~ > cat /proc/slabinfo | grep inode
    inode_cache 136909 136932
    andrea@laser:~ > cat /proc/slabinfo | grep dentry
    dentry_cache 154681 155000

    256 spurious_interrupt_bug 21.3333
    724 __strncpy_from_user 20.1111
    2023 do_anonymous_page 16.3145
    759 system_call 13.5536
    921 file_read_actor 12.1184
    471 __udelay 7.8500
    490 __generic_copy_from_user 7.6562
    153 __get_user_1 7.6500
    163 signal_return 6.7917
    228 sock_mmap 6.3333
    479 sock_poll 4.2768
    41 coprocessor_error 3.4167
    54 ret_with_reschedule 3.3750
    410 unix_poll 2.5000
    567 free_wait 2.4868
    314 ide_config_drive_speed 2.4531
    82 get_hardblocksize 2.2778
    1654 do_select 2.2473
    33 restore_all 2.2000
    756 interruptible_sleep_on 2.0323
    88 find_inode 1.6923
    754 __get_free_pages 1.6391
    308 d_lookup 1.4808

    Without enlarging the hash the find_inode would be at the first hit with
    an huge value. Right now instead everything goes fine very fast and when
    the system will need memory the icache/dcache are shrunk automagically.

    BTW, but I have not yet asked myself what the weird
    "spurious_interrupt_bug" at the top of the profiling is 8).


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:54    [W:0.022 / U:3.308 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site