lkml.org 
[lkml]   [2003]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch for playing] 2.5.65 patch to support > 256 disks
    On Wed, Mar 26 2003, Badari Pulavarty wrote:
    > On Tuesday 25 March 2003 04:35 am, Jens Axboe wrote:
    >
    > > Only testing will tell, so yes you are very welcome to give it a shot.
    > > Let me release a known working version first :)
    >
    > Jens,
    >
    > I found whats using 32MB out of 8192-byte slab.
    >
    > size-8192 before:10 after:4012 diff:4002 size:8192 incr:32784384
    >
    > It is deadline_init():
    >
    > dd->hash = kmalloc(sizeof(struct list_head)*DL_HASH_ENTRIES,GFP_KERNEL);
    >
    > It is creating 8K hash table for each queue. Since we have 4000 queues,

    Yes

    > it used 32MB. I wonder why the current code needs 1024 hash buckets,

    Hmm actually that's a leftover from when we played with bigger queue
    sizes, I inadvertently forgot to change it back when pushing the rbtree
    deadline update to Linus. It used to be 256. We can shrink this to 2^7
    or 2^8 instead, which will then only eat 1-2K.

    > when maximum requests are only 256. And also, since you are making
    > request allocation dynamic, can you change this too ? Any issues here ?

    No real issues to shrinking it, bigger problem if we move to larger
    queues. With the rq-dyn-alloc patch, we can make the max number of
    requests ceiling a lot higher and then the hash needs to be bigger too.
    But for now, 256 entry should be a good default and suffice for the
    future, I'll push that change.

    --
    Jens Axboe

    -
    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:34    [W:3.889 / U:0.428 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site