Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
From:   Florian Weimer <fweimer@redhat.com>
To:     Waiman Long <longman@redhat.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Juri Lelli <juri.lelli@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Valentin Schneider <vschneid@redhat.com>,
        linux-kernel@vger.kernel.org, Phil Auld <pauld@redhat.com>,
        Brent Rowsell <browsell@redhat.com>,
        Peter Hunt <pehunt@redhat.com>
Subject: Re: [PATCH v4] sched/core: Use zero length to reset cpumasks in
 sched_setaffinity()
References: <20231003205735.2921964-1-longman@redhat.com>
        <20231004083648.GI27267@noisy.programming.kicks-ass.net>
        <871qeaefco.fsf@oldenburg.str.redhat.com>
        <4a4076c4-c6ad-063d-a2e1-3048cf71f723@redhat.com>
Date:   Wed, 04 Oct 2023 14:55:10 +0200
In-Reply-To: <4a4076c4-c6ad-063d-a2e1-3048cf71f723@redhat.com> (Waiman Long's
        message of "Wed, 4 Oct 2023 08:41:21 -0400")
Message-ID: <87mswycztd.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

* Waiman Long:

> On 10/4/23 08:34, Florian Weimer wrote:
>> * Peter Zijlstra:
>>
>>> Subject: sched: Add CPU_FILL()
>>>
>>> Add the CPU_FILL() macros to easily create an all-set cpumask.
>>>
>>> FreeBSD also provides this macro with this semantic.
>>>
>>> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>> My main concer is that obtaining the size of the mask, or at least an
>> approximiation is not exactly easy.  If there's an expectation that
>> applications reset the mask more often than they do today (I don't have
>> the full context here), then we'd some decent interface to get the
>> approriate size.
>
> I believe the macro just use sizeof(cpu_set_t) as the size of the
> bitmask. It is the same case as in CPU_ZERO().

I mean the CPU_FILL_S macro also defined in the patch.  Correctly
written applications should not use CPU_FILL and statically sized CPU
sets.

Thanks,
Florian