Messages in this thread |  | | | Date | Mon, 11 Jul 2005 17:20:11 +0200 | | From | Eric Dumazet <> | | Subject | Re: [PATCH] eventpoll : Suppress a short lived lock from struct file |
| |
Davide Libenzi a écrit :
> Eric, I can't really say I like this one. Not at least after extensive > tests run on top of it.
fair enough :)
> You are asking to add a bottleneck to save 8 > bytes on an entity that taken alone in more than 120 bytes. Consider > that when you have a "struct file" allocated, the cost on the system is > not only the struct itself, but all the allocations associated with it. > For example, if you consider that a case where you might feel a "struct > file" pressure is when you have hundreds of thousands of network > connections, the 8 bytes saved compared to all the buffers associated > with those sockets boils down to basically nothing.
Well, the filp_cachep slab is created with SLAB_HWCACHE_ALIGN, enforcing a alignment of 64 bytes or even 128 bytes.
So it can be usefull to let the size of struct file goes from 0x84 to 0x80, because we can gain 64 or 128 bytes per file (0x80 bytes really allocated instead of 0xc0 or even 0x100 on Pentium 4).
In my case, I use other patches outside the scope of eventpoll (like declaring f_security only #ifdef CONFIG_SECURITY_SELINUX), and really gain 128 bytes of low memory per file. It reduces cache pressure for a given workload, and reduce lowmem pressure.
Before :
# grep filp /proc/slabinfo filp 66633 66750 256 15 1 : tunables 120 60 8 : slabdata 4450 4450 60
After :
# grep filp /proc/slabinfo filp 82712 82987 128 31 1 : tunables 120 60 8 : slabdata 2677 2677 20
It may appears to you as a penalty, but at least for me it is a noticeable gain.
Another candidate to "file struct" size reduction is the big struct file_ra_state that is included in all files, even sockets that dont use it, but that's a different story :)
Eric - 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/
|  |