linux-kernel - Re: [PATCH] epoll: trim epitem by one cache line on x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Mar 2013 14:37:41 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Eric Wong <normalperson@...t.net>
Cc:	Davide Libenzi <davidel@...ilserver.org>,
	Al Viro <viro@...IV.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] epoll: trim epitem by one cache line on x86_64

On Mon, 4 Mar 2013 11:29:41 +0000 Eric Wong <normalperson@...t.net> wrote:

> It is common for epoll users to have thousands of epitems, so saving a
> cache line on every allocation leads to large memory savings.
> 
> Since epitem allocations are cache-aligned, reducing sizeof(struct
> epitem) from 136 bytes to 128 bytes will allow it to squeeze under a
> cache line boundary on x86_64.
> 
> >From /sys/kernel/slab/eventpoll_epi, I see the following changes on my
> x86_64 Core2 Duo (which has 64-byte cache alignment):
> 
> 	object_size  :  192 => 128
> 	objs_per_slab:   21 =>  32
> 
> I have no access to other 64-bit machines, so I am limiting this to
> x86_64-only with EPOLL_PACKED instead of __attribute__((packed))
> 
> ...
>
> --- a/fs/eventpoll.c
> +++ b/fs/eventpoll.c
> @@ -107,7 +107,7 @@
>  struct epoll_filefd {
>  	struct file *file;
>  	int fd;
> -};
> +} EPOLL_PACKED;
>  
>  /*
>   * Structure used to track possible nested calls, for too deep recursions

Yes, I see the same numbers on my gcc, x86_64 allmodconfig.

It's going to be hard to maintain this - someone will change something
sometime and break it.  I suppose we could add a runtime check if we
cared enough.  Adding a big fat comment to struct epitem might help.

I don't see much additional room to be saved.  We could probably remove
epitem.nwait, but that wouldn't actually save anything because nwait
nestles with ffd.fd.

I tested your patch on powerpc and it reduced sizeof(epitem) from 136
to 128 for that arch as well, so I suggest we run with

--- a/fs/eventpoll.c~epoll-trim-epitem-by-one-cache-line-on-x86_64-fix
+++ a/fs/eventpoll.c
@@ -105,7 +105,7 @@
 struct epoll_filefd {
 	struct file *file;
 	int fd;
-} EPOLL_PACKED;
+} __packed;
 
 /*
  * Structure used to track possible nested calls, for too deep recursions
_

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/