On Tue, 11 Apr 2000, Andi Kleen wrote:
>How about the loop in get_request ? It looks rather inefficient.
Oh definitely, as opposite to the elevator the get_request operation run
without wake-one would be evil with a long and empty request queue
(exactly as in 2.2.x).
>Wouldn't it be better to have a free list of requests ?
Agreed, it's certainly possible and worthy to optimize that bit to avoid
browsing the queue each time we run out of requests.
>AFAIK interrupts near always run as soon as they are unblocked.
On IA32 we have a 1 asm instruction gap before sti have effect for
example. I only wanted to point out the "soon" is variable :).
>The main problem with the dentry and inode hashes is that they waste twice
>the memory they should (anchored list heads are *very* wasteful for hash
>tables). It is rather unlikely that the cost of the few saved if()s in the
>list macros weight up for the additional cache misses [patch will come
>as soon as I have tested it a bit more]
You are perfectly right, but I really don't think it's for the speed but
for being allowed to use the list.h interface (at least that's why I used
the anchored list head in the write-COW fast path lookup of the
lvm-snapshot code even if I known I wasn't optimizing memory usage ;). I
strongly disagree in adding further by hand stuff like what we have just
for the buffer and page cache hashtables. We do need the same interface of
list.h _but_ that uses a single word sized head.
>If you look at nm --size-sort -t d vmlinux you'll see that dentry
>and inode hash are the biggest static memory wasters.
That's expected because there aren't other relevant _static_ hashtable
into the kernel. The other hashes are all dynamic luckily ;). As soon as
such two hashes will be dynamic too, nm --size-sort -t d vmlinux won't
show them anymore ;) (in 2.2.x the dentry hash won't show just now).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:16 EST