> +/**
> + * ampress_notify - dispatch a memory pressure event to all subscribers
> + * @urgency: AMPRESS_URGENCY_* level
> + * @numa_node: NUMA node of the pressure source (0xFF = system-wide)
> + * @requested_kb: Suggested reclaim target in KiB (0 = unspecified)
> + *
> + * Must be safe to call from any context including IRQ / reclaim paths:
> + * - no sleeping allocations
> + * - only spin_lock_irqsave and wake_up_interruptible
> + */
> +void ampress_notify(int urgency, int numa_node, unsigned long requested_kb)
> +{
> + struct ampress_subscriber *sub;
> + unsigned long rflags, flags;
> + int notified = 0;
> +
> + /*
> + * Use irqsave variants: ampress_notify() may be called from a context
> + * where interrupts are disabled (e.g. a future direct-reclaim hook).
> + */
> + read_lock_irqsave(&ress_subscribers_lock, rflags);
> + list_for_each_entry(sub, &ress_subscribers, list) {
> + if (!sub->subscribed)
> + continue;
> +
> + /*
> + * Check if the urgency meets or exceeds the subscriber's
> + * configured threshold for this urgency level.
> + *
> + * Default config has all thresholds at 0, meaning any
> + * urgency >= 0 passes — i.e. everything is delivered.
> + */
> + spin_lock_irqsave(&sub->lock, flags);
> + sub->pending_event.urgency = (__u8)urgency;
> + sub->pending_event.numa_node = (__u8)(numa_node & 0xFF);
> + sub->pending_event.reserved = 0;
> + sub->pending_event.requested_kb =
> + (__u32)min_t(unsigned long, requested_kb, U32_MAX);
I didn't take a detailed look, but this one confused me while skimming
over some bits: Which value does exposing requested_kb really have if
there are multiply subscribers to notify? Doesn't quite make sense to
even expose that.
Assume it's 2 MiB and you notify 1024 processes. Are you suddenly
getting 2 GiB back?
On a bigger picture, I don't think the whole idea of having multiple
subscribers is really thought through.
What are some arbitrary processes supposed to do if the receive one of
the notifications? How much memory are they supposed to reclaim (given
that requested_kb is questionable)? How are they supposed to reclaim the
memory (MADV_DONTNEED? MADV_PAGEOUT? or what else?). There is a lot of
information missing from the patch description to understand the bigger
picture.
If apps have droppable caches, a better solution might be to use
something like MAP_DROPPABLE where possible, still leaving the kernel in
charge of when and how much memory to reclaim.
--
Cheers,
David
