netdev - Re: [PATCH] ipv4: move rt_genid to different cache line

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] [day] [month] [year] [list]

Message-Id: <20140103.194811.1577005821228999480.davem@davemloft.net>
Date:	Fri, 03 Jan 2014 19:48:11 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	therbert@...gle.com
Cc:	netdev@...r.kernel.org, eric.dumazet@...il.com
Subject: Re: [PATCH] ipv4: move rt_genid to different cache line

From: Tom Herbert <therbert@...gle.com>
Date: Thu, 2 Jan 2014 12:00:23 -0800 (PST)

> Running a simple netperf TCP_RR test with 200 clients shows that
> ipv4_dst_check is high on the list of functions in 'perf top'. The
> pertinent action in this function is in the call to rt_is_expired
> which checks the route genid (rt->rt_gentid) against the global value.
> rt_genid is in the same cacheline as dst->__refcnt which is causing
> false sharing.
> 
> This fix moves rt_genid into the first cacheline of the dst structure.
> The dst structue is explicitly packed for cacheline optimization, so to
> make room for the genid, I moved xfrm to cacheline with __refcnt (under
> the assumption it is less likely to be in the critical path).
> 
> I don't believe there is an issue in ip6_dst_check since rt6i_genid
> and the dst are in separate cachelines already (struct rt6_info).
> 
> Signed-off-by: Tom Herbert <therbert@...gle.com>

Can you just put the genid deeper into "struct rtable" to solve this?

It might work well to put it next to the uncached list.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html