netdev - Re: [PATCH] net: fix kmemcheck annotations

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:	Thu, 29 Oct 2009 11:44:48 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	David Miller <davem@...emloft.net>
CC:	netdev@...r.kernel.org
Subject: Re: [PATCH] net: fix kmemcheck annotations

David Miller a écrit :
> 
> We may be trading size for performance here, I wonder if
> it's wise to move queue_mapping like that and what
> locality change we get as a result.

I agree, but could not convince me it makes a difference.

On 64bit arches, queue_mapping doesnt change its cache line location
(0xa4 -> 0xa8)

On 32bit arches, sizeof(sk_buf)=0xB0, rx and tx paths touch all
 of 3 cache lines anyway.

Only thing I can think at this moment is to reorder skb so that TX 
completion path dont touch all cache lines (putting together cb[] 
and some not touched fields). We could probably gain one cache line miss.

It's a bit hard because of the next/prev fields that must
be first members of structure, but I believe you had some work in progress
in this area, to stick a standard list_head ?

--
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