On Mon, Jun 08, 2026 at 04:21:08PM -0400, Zi Yan wrote:
> On 8 Jun 2026, at 15:59, Gregory Price wrote:
>
> > On Mon, Jun 08, 2026 at 02:04:28PM +0100, Matthew Wilcox wrote:
> >> On Mon, Jun 08, 2026 at 12:06:35PM +0100, Lorenzo Stoakes wrote:
> >>> But instead of overloading user_addr to indicate all kinds of things,
> >>> instead
> >>> make life easier by actually breaking things out.
> >>>
> >>> Like:
> >>>
> >>> enum alloc_context_type {
> >>> KERNEL_ALLOCATION,
> >>> USER_MAPPED_ALLOCATION,
> >>> USER_UNMAPPED_ALLOCATION, // Maybe? Do we ever?
> >>> /* Perhaps some other states we want to encode? */
> >>> };
> >>>
> >>> struct alloc_context {
> >>> ...
> >>>
> >>> enum alloc_context_type type;
> >>> unsigned long user_addr; // Only set if type == USER_ALLOCATION
> >>>
> >>> // Maybe something suggesting context or whether we init before in some
> >>> // cases?
> >>> };
> >>
> >> Ugh, please, no. As I suggested last time I commented on this
> >> trainwreck of a series, lift the zeroing functionality from
> >> alloc_frozen_pages() into its callers.
> >
> > This sort of just implies writing the "alloc_frozen_zeroed_pages()"
> > wrapper that does the zeroing at the end before return, and then killing
> > the post hook nonsense associated with it in the first place.
>
> This means it is going to be a multi-step optimization. This is probably
> step 1.
>
> >
> > None of this resolves the user address annoyance which is needed on some
> > archs for cache flushing. Whether anyone agrees that the page allocator
> > should be responsible for this particular operation - open debate.
>
> This is probably step 2. But does the virtio use case apply to these
> archs? Does the performance matter for them? If not, maybe this part can
> be left as a TODO.
>
>
> Best Regards,
> Yan, Zi
I doubt it. But I don't get what's proposed, the code that we
have to modify is arch independent?
