Re: [PATCH] eventpoll : Suppress a short lived lock from struct file

[Eric Dumazet]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/