Re: [PATCH 6/6] x86/xstate: Switch back to for_each_set_bit()

2024-06-27 Thread Jan Beulich
On 26.06.2024 20:09, Andrew Cooper wrote: > On 26/06/2024 11:24 am, Jan Beulich wrote: >> On 25.06.2024 21:07, Andrew Cooper wrote: >>> In all 3 examples, we're iterating over a scaler. No caller can pass the >>> COMPRESSED flag in, so the upper bound of 63, as opposed to 64, doesn't >>> matter. >

Re: [PATCH 6/6] x86/xstate: Switch back to for_each_set_bit()

2024-06-26 Thread Andrew Cooper
On 26/06/2024 11:24 am, Jan Beulich wrote: > On 25.06.2024 21:07, Andrew Cooper wrote: >> In all 3 examples, we're iterating over a scaler. No caller can pass the >> COMPRESSED flag in, so the upper bound of 63, as opposed to 64, doesn't >> matter. > Not sure, maybe more a language question (for m

Re: [PATCH 6/6] x86/xstate: Switch back to for_each_set_bit()

2024-06-26 Thread Jan Beulich
On 25.06.2024 21:07, Andrew Cooper wrote: > In all 3 examples, we're iterating over a scaler. No caller can pass the > COMPRESSED flag in, so the upper bound of 63, as opposed to 64, doesn't > matter. Not sure, maybe more a language question (for my education): Is "can" really appropriate here? I

[PATCH 6/6] x86/xstate: Switch back to for_each_set_bit()

2024-06-25 Thread Andrew Cooper
In all 3 examples, we're iterating over a scaler. No caller can pass the COMPRESSED flag in, so the upper bound of 63, as opposed to 64, doesn't matter. This alone produces: add/remove: 0/0 grow/shrink: 0/4 up/down: 0/-161 (-161) Function old new del