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

Eric Dumazet
2005-07-11T15:23:37Z

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