lkml.org 
[lkml]   [2023]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v4] sched/core: Use zero length to reset cpumasks in sched_setaffinity()
    From
    On 10/4/23 06:06, Ingo Molnar wrote:
    > * Peter Zijlstra <peterz@infradead.org> wrote:
    >
    >> On Wed, Oct 04, 2023 at 11:23:41AM +0200, Ingo Molnar wrote:
    >>
    >>>> if (user_mask) {
    >>>> - cpumask_copy(user_mask, in_mask);
    >>>> + /*
    >>>> + * All-set user cpumask resets affinity and drops the explicit
    >>>> + * user mask.
    >>>> + */
    >>>> + cpumask_and(user_mask, in_mask, cpu_possible_mask);
    >>>> + if (cpumask_equal(user_mask, cpu_possible_mask)) {
    >>>> + kfree(user_mask);
    >>>> + user_mask = NULL;
    >>>> + }
    >>> Question: is there any observable behavioral difference between current
    >>> (old) all-set cpumask calls and the patched (new) one?
    >> Very little I think -- the main difference is that we no longer carry
    >> the ->user_cpus_ptr mask around, and that saves a little masking.
    > So calling with a full mask would actually work fine on 'old' kernels too,
    > as it's a 'reset' event in essence. (With a bit of allocation & masking
    > overhead.)
    >
    > This pretty unambiguously marks the full-mask solution as the superior ABI ...

    I am fine with that one too. I do have a little bit concern about that
    the difference in behavior when the full mask is passed in, but that is
    reverting to the old behavior before commit 8f9ea86fdf99 ("sched: Always
    preserve the user requested cpumask").

    BTW, we can probably check the in_mask directly earlier to skip an
    unnecessary cpumask allocation and free in this particular case.

    Cheers,
    Longman

    \
     
     \ /
      Last update: 2023-10-04 14:21    [W:4.098 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site