netdev - Re: [PATCH -next] hfsc: reduce hfsc

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:	Mon, 4 Jul 2016 19:57:35 +0200
From:	Michal Soltys <soltys@....info>
To:	Florian Westphal <fw@...len.de>, netdev@...r.kernel.org
Subject: Re: [PATCH -next] hfsc: reduce hfsc_sched to 14 cachelines

On 2016-07-04 16:22, Florian Westphal wrote:
> hfsc_sched is huge (size: 920, cachelines: 15), but we can get it to 14
> cachelines by placing level after filter_cnt (covering 4 byte hole) and
> reducing period/nactive/flags to u32 (period is just a counter,
> incremented when class becomes active -- 2**32 is plenty for this
> purpose, also, long is only 32bit wide on 32bit platforms anyway).
> 
> cl_vtperiod is exported to userspace via tc_hfsc_stats, but its period
> member is already u32, so no precision is lost there either.
> 

It should be fine, even if it overflowed (which theoretically isn't that
hard: 1500 mtu, 1gbit interface, 900mbit transfer (meaning some process
throttling itself to 900mbit, not hfsc upperlimiting it) => ~16 hours to
overflow or ITOW 75000 period changes/s) - what really matters (in
init_vf()) is if the period is different.

For the record, I have 2 patches that will trim some stuff further.
Unfortunately I have another 2 that will near surely put it back at
[hopefully only] 16 (if they get accepted that is).

But there're some other candidates that might help (some not that tiny
functions defined as inline that are called in more than 1 place). E.g.
update_cfmin() is called from 3 places.