lkml.org 
[lkml]   [1999]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: inode_lock "decorative"?
On Fri, 26 Nov 1999 kuznet@ms2.inr.ac.ru wrote:

>which is reserved by FS instances. Do you see? If "dummy" inodes are private,
>we can easily invent a way to allocate/release them from net and save
>lots of space and dereferences sock <-> socket.

Yes. I think that's exactly what Alexander was talking about.

>[..] The only things to do is close()/poll()/ioctl().

Of course the network can't drop the lock from there without breaking the
rest ;).

>(snmp counters etc.). I will convert them to cpu local vars in one hit,

Good idea, so you'll avoid the lock and you'll have to do the sum (without
locks too) only at /proc read time.

>BTW why not to create NR_CPUS bss sections?

So also NR_CPUS .data and "maybe" each one starting cacheline aligned,
right? ;). Yes looks like a good idea and would save lots of memory as
everybody is enlarging his structures to go cacheline aligned. Then we
could remove all the ugly stuff like the aligned_data union in sched.c...

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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.146 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site