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.
