linux-kernel - Re: [RFC 1/3] /dev/low_mem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Jan 2012 11:15:41 +0200
From:	Pekka Enberg <penberg@...nel.org>
To:	leonid.moiseichuk@...ia.com
Cc:	riel@...hat.com, minchan@...nel.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, kamezawa.hiroyu@...fujitsu.com,
	mel@....ul.ie, rientjes@...gle.com, kosaki.motohiro@...il.com,
	hannes@...xchg.org, mtosatti@...hat.com, akpm@...ux-foundation.org,
	rhod@...hat.com, kosaki.motohiro@...fujitsu.com
Subject: Re: [RFC 1/3] /dev/low_mem_notify

On Wed, Jan 18, 2012 at 11:06 AM,  <leonid.moiseichuk@...ia.com> wrote:
> Would be possible to not use percents for thesholds? Accounting in pages even
> not so difficult to user-space.

How does that work with memory hotplug?

On Wed, Jan 18, 2012 at 11:06 AM,  <leonid.moiseichuk@...ia.com> wrote:
> Also, looking on vmnotify_match I understand that events propagated to
> user-space only in case threshold trigger change state from 0 to 1 but not
> back, 1-> 0 is very useful event as well.
>
> Would be possible to use for threshold pointed value(s) e.g. according to
> enum zone_state_item, because kinds of memory to track could be different?
> E.g. to tracking paging activity NR_ACTIVE_ANON and NR_ACTIVE_FILE could be
> interesting, not only free.

I don't think there's anything in the ABI that would prevent that.

>> +struct vmnotify_event {
>> +     /* Size of the struct for ABI extensibility. */
>> +     __u32                   size;
>> +
>> +     __u64                   nr_avail_pages;
>> +
>> +     __u64                   nr_swap_pages;
>> +
>> +     __u64                   nr_free_pages;
>> +};
>
> Two fields here most likely session-constant, (nr_avail_pages and
> nr_swap_pages), seems not much sense to report them in every event.  If we
> have memory/swap hotplug user-space can use sysinfo() call.

I actually changed the ABI to look like this:

struct vmnotify_event {
        /*
         * Size of the struct for ABI extensibility.
         */
        __u32                   size;

        __u64                   attrs;

        __u64                   attr_values[];
};

So userspace can decide which fields to include in notifications.

On Wed, Jan 18, 2012 at 11:06 AM,  <leonid.moiseichuk@...ia.com> wrote:
>> +static void vmnotify_sample(struct vmnotify_watch *watch) {
> ...
>> +     si_meminfo(&si);
>> +     event.nr_avail_pages    = si.totalram;
>> +
>> +#ifdef CONFIG_SWAP
>> +     si_swapinfo(&si);
>> +     event.nr_swap_pages     = si.totalswap;
>> +#endif
>> +
>
> Why not to use global_page_state() directly? si_meminfo() and especial
> si_swapinfo are quite expensive call.

Sure, we can do that. Feel free to send a patch :-).

>> +static void vmnotify_start_timer(struct vmnotify_watch *watch) {
>> +     u64 sample_period = watch->config.sample_period_ns;
>> +
>> +     hrtimer_init(&watch->timer, CLOCK_MONOTONIC,
>> HRTIMER_MODE_REL);
>> +     watch->timer.function = vmnotify_timer_fn;
>> +
>> +     hrtimer_start(&watch->timer, ns_to_ktime(sample_period),
>> +HRTIMER_MODE_REL_PINNED); }
>
> Do I understand correct you allocate timer for every user-space client and
> propagate events every pointed interval?  What will happened with system if
> we have a timer but need to turn CPU off? The timer must not be a reason to
> wakeup if user-space is sleeping.

No idea what happens. The sampling code is just a proof of concept thing and I
expect it to be buggy as hell. :-)

			Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/