git: d1cbe7908986 - main - Allocating the LinuxKPI current structure from an interrupt thread must be done using the M_NOWAIT flag after 1ae20f7c70ea .

[Konstantin Belousov]

On Thu, Mar 11, 2021 at 08:20:05PM +0100, Hans Petter Selasky wrote:
> On 3/11/21 8:04 PM, Konstantin Belousov wrote:
> > On Thu, Mar 11, 2021 at 07:41:53PM +0100, Hans Petter Selasky wrote:
> > > On 3/11/21 7:35 PM, Konstantin Belousov wrote:
> > > > And I dislike this.  It is yet another case of introducing consumer-specific
> > > > logic into core.  Isn't netepoch example enough?
> > > > 
> > > > I presented another patch to Hans, where task and mm allocations are
> > > > switched to zones, and the zones have reserve applied. Then allocations
> > > > from ithreads use the reserve.
> > > > 
> > > > There is one detail there, reserve is finite, for x86 I set it to the
> > > > total limit of interrupts. This somewhat breaks if interrupts are
> > > > deallocated and reallocated, but I think it is good enough even with
> > > > this wart.
> > > 
> > > Hi,
> > > 
> > > Your patch doesn't address the issue of initializing the pointers in
> > > question once. Still, for every call, we need to check if the pointer is
> > > valid. This is not neccessary.
> > I do not understand what you are saying there.
> > Which pointers?  How does it not address?
> 
> Hi,
> 
> The current code calls linux_set_current() for every interrupt and timer
> callback. That means we continue to check td_lkpi_task for NULL for every
> one of these calls. Not strictly needed.
And how this would change?  The linux_set_current() calls are spread all
over the linuxkpi code, so
- you cannot eliminate them for interrupt thread context
- they are already there anyway.

What is your point?
> 
> > 
> > > 
> > > Also I don't see why we need to create a own UMA zone for these simple
> > > structures. Won't the per-CPU sysctl consume more memory than the actual
> > > task structures being allocated?
> > Dedicated UMA zone allows to gracefully solve the requirement of non-failing
> > allocation in non-sleepable context.  This is much simpler and cleaner than
> > either trying to enumerate all existing ithreads or adding consumer-specific
> > controls into generic kernel facility.
> > 
> 
> Maybe I'm new to UMA zones. The M_USE_RESERVE can also be used with malloc()
> ?
Yes M_USE_RESERVE can be used on zones without reserve (like malloc zones),
but it would have a different meaning.  On allocation failure due to low
memory, for zones with reserve, it means:
- first look at reserve, and if nothing left, you are allowed to consume
  the last free page in the system
For zones without reserve, it just allows to utilize the last free page.
In other words, if you have a reserve in zone, alloc requests are guaranteed
to not fail regardless of the free memory.