Hi,
On 3/12/21 1:00 PM, Konstantin Belousov wrote:
On Thu, Mar 11, 2021 at 08:20:05PM +0100, Hans Petter Selasky wrote:
...
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
Regular interrupt threads typically don't use the "current" or "task
structure" at all.
- they are already there anyway.
For user-space, yes.
What is your point?
I still believe an own UMA zone is overkill for the purpose of task_struct .
We could just pre-allocate these structures into a linked list, and
dequeue these for interrupt threads only. Every time a new interrupt is
allocated we allocate one more of these structures beforehand, and then
we use that structure back when the ITHREAD flags is set in the thread
structure, similar to what you are doing, except we don't use UMA zones.
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.
OK.
--HPS
_______________________________________________
dev-commits-src-main@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main
To unsubscribe, send any mail to "dev-commits-src-main-unsubscr...@freebsd.org"
