> On Jan 29, 2020, at 7:18 AM, Taylor R Campbell
> wrote:
>
> I don't think so, because it's OK for the percpu_foreach callback to
> mutex_enter/exit on an adaptive lock even though that might sleep.
> What's not OK is sleeping for allocation or other long durations.
> Merely holding
[Cc'ing the wizards at IIJ because a diagnostic measure we're
discussing may require adapting the network stack.]
> Date: Wed, 29 Jan 2020 05:43:39 -0800
> From: Jason Thorpe
>
> > On Jan 28, 2020, at 9:46 PM, Taylor R Campbell
> > wrote:
> >
> > Normally sleeping under percpu_getref -- even
> On Jan 28, 2020, at 9:46 PM, Taylor R Campbell
> wrote:
>
>> Date: Tue, 28 Jan 2020 20:49:50 -0800
>> From: Jason Thorpe
>>
>> What happens if:
>>
>> oink = percpu_getref(...);
>> ...
>> mutex_enter(...); // blocks for a long time for whatever reason.
>> //
> Date: Tue, 28 Jan 2020 20:49:50 -0800
> From: Jason Thorpe
>
> What happens if:
>
> oink = percpu_getref(...);
> ...
> mutex_enter(...); // blocks for a long time for whatever reason.
> // while we're blocked, someone else does a percpu_alloc() that results
>
> On Jan 28, 2020, at 8:37 PM, Taylor R Campbell
> wrote:
>
> The reason percpu_foreach takes percpu_swap_lock is so that the
> pointer percpu_getptr_remote returns remains stable _without_
> percpu_getref/putref.
What happens if:
oink = percpu_getref(...);
...
> Date: Tue, 28 Jan 2020 20:00:00 -0800
> From: Jason Thorpe
>
> Hm, actually, I think you are right, but because of a property of
> xcalls themselves...
>
> -- percpu_cpu_swap() is a low-pri xcall, and thus won't run
> concurrently with a low-pri percpu_foreach_xcall(), so no need to
> grab
> On Jan 28, 2020, at 7:11 PM, Taylor R Campbell
> wrote:
>
>> Date: Tue, 28 Jan 2020 18:54:59 -0800
>> From: Jason Thorpe
>>
>> Something like this. I haven't tested this yet, but I will shortly.
>> Only high-pri xcalls are supported in this -- to make low-pri xcalls
>> work, you'd need
> Date: Tue, 28 Jan 2020 18:54:59 -0800
> From: Jason Thorpe
>
> Something like this. I haven't tested this yet, but I will shortly.
> Only high-pri xcalls are supported in this -- to make low-pri xcalls
> work, you'd need to change how percpu_cpu_swap() interlocks with
> percpu_foreach().
> On Jan 28, 2020, at 9:20 AM, Taylor R Campbell
> wrote:
>
> OK, that sounds reasonable. (I misunderstood your first message to
> mean that percpu_foreach_xcall would synchronize with _other activity_
> on each CPU, rather than that it would serialize the xcall with itself
> on different
> Date: Tue, 28 Jan 2020 09:08:22 -0800
> From: Jason Thorpe
>
> >> 2- If I were to use xc_broadcast(), then in the case of network
> >> protocol / interface stats, I would need to use either atomic
> >> operations or add some other synchronization into the shared
> >> "exported copy" of the
> On Jan 28, 2020, at 9:01 AM, Taylor R Campbell
> wrote:
>
> I see percpu_foreach as being primarily aimed at initialization and
> finalization, for which it is entirely reasonable -- and, at boot
> time, perhaps necessary -- to run on the current CPU.
Sure, but that's not the way it's used
> Date: Tue, 28 Jan 2020 08:52:35 -0800
> From: Jason Thorpe
>
> 1- This seems to be a general issue with percpu_foreach(). I mean,
> one of the main purposes of per-cpu storage is that other CPUs don't
> touch it, and percpu_foreach() completely violates the POLA in this
> regard.
I see
> On Jan 28, 2020, at 8:40 AM, Taylor R Campbell
> wrote:
>
> Why not just use xc_broadcast? Does a cross-calling version of
> percpu_foreach really help simplify much or clarify anything?
I suppose I could, but:
1- This seems to be a general issue with percpu_foreach(). I mean, one of
> Date: Mon, 27 Jan 2020 18:36:17 -0800
> From: Jason Thorpe
>
> So, percpu_foreach() is pretty handy for enumerating data that's
> managed on a per-cpu basis. But there's a problem ... it does not
> actually execute the callback on the remote CPU, instead getting a
> pointer to the remote data
So, percpu_foreach() is pretty handy for enumerating data that's managed on a
per-cpu basis. But there's a problem ... it does not actually execute the
callback on the remote CPU, instead getting a pointer to the remote data and
accessing it directly.
Does this seem like a problem to anyone
15 matches
Mail list logo
