Re: [PATCH 3/3] vmevent: Implement special low-memory attribute

[KOSAKI Motohiro]

(5/8/12 3:36 AM), Pekka Enberg wrote:
> On Tue, May 8, 2012 at 10:11 AM, KOSAKI Motohiro
> <kosaki.motohiro@xxxxxxxxx>  wrote:
> > Ok, sane. Then I take my time a little and review current vmevent code briefly.
> > (I read vmevent/core branch in pekka's tree. please let me know if
> > there is newer repositry)
>
> It's the latest one.
>
> On Tue, May 8, 2012 at 10:11 AM, KOSAKI Motohiro
> <kosaki.motohiro@xxxxxxxxx>  wrote:
> > 1) sample_period is brain damaged idea. If people ONLY need to
> > sampling stastics, they
> >   only need to read /proc/vmstat periodically. just remove it and
> > implement push notification.
> >   _IF_ someone need unfrequent level trigger, just use
> > "usleep(timeout); read(vmevent_fd)"
> >   on userland code.
>
> That comes from a real-world requirement. See Leonid's email on the topic:
>
> https://lkml.org/lkml/2012/5/2/42

I know, many embedded guys prefer such timer interval. I also have an experience
similar logic when I was TV box developer. but I must disagree. Someone hope
timer housekeeping complexity into kernel. but I haven't seen any justification.


> > 2) VMEVENT_ATTR_STATE_ONE_SHOT is misleading name. That is effect as
> > edge trigger shot. not only once.
>
> Would VMEVENT_ATTR_STATE_EDGE_TRIGGER be a better name?

maybe.


> > 3) vmevent_fd() seems sane interface. but it has name space unaware.
> > maybe we discuss how to harmonize name space feature.  No hurry. but we have
> > to think that issue since at beginning.
>
> You mean VFS namespaces? Yeah, we need to take care of that.

If we keep current vmevent_fd() design, we may need to create new namespace concept
likes ipc namespace. current vmevent_fd() is not VFS based.


> > 4) Currently, vmstat have per-cpu batch and vmstat updating makes 3
> > second delay at maximum.
> >   This is fine for usual case because almost userland watcher only
> > read /proc/vmstat per second.
> >   But, for vmevent_fd() case, 3 seconds may be unacceptable delay. At
> > worst, 128 batch x 4096
> >   x 4k pagesize = 2G bytes inaccurate is there.
>
> That's pretty awful. Anton, Leonid, comments?
>
> > 5) __VMEVENT_ATTR_STATE_VALUE_WAS_LT should be removed from userland
> > exporting files.
> >   When exporing kenrel internal, always silly gus used them and made unhappy.
>
> Agreed. Anton, care to cook up a patch to do that?
>
> > 6) Also vmevent_event must hide from userland.
>
> Why? That's part of the ABI.

Ahhh, if so, I missed something. as far as I look, vmevent_fd() only depend
on vmevent_config. which syscall depend on vmevent_evennt?



> > 7) vmevent_config::size must be removed. In 20th century, M$ API
> > prefer to use this technique. But
> >   They dropped the way because a lot of application don't initialize
> > size member and they can't use it for keeping upper compitibility.
>
> It's there to support forward/backward ABI compatibility like perf
> does. I'm going to keep it for now but I'm open to dropping it when
> the ABI is more mature.

perf api is not intended to use from generic applications. then, I don't
think it will make abi issue. tool/perf is sane, isn't it? but vmevent_fd()
is generic api and we can't trust all userland guy have sane, unfortunately.

> > 8) memcg unaware
> > 9) numa unaware
> > 10) zone unaware
>
> Yup.
>
> > And, we may need vm internal change if we really need lowmem
> > notification. current kernel don't have such info. _And_ there is one more
> > big problem. Currently the kernel maintain memory per
> > zone. But almost all userland application aren't aware zone nor node.
> > Thus raw notification aren't useful for userland. In the other hands, total
> > memory and total free memory is useful? Definitely No!
> > Even though total free memory are lots, system may start swap out and
> > oom invokation. If we can't oom invocation, this feature has serious raison
> > d'etre issue. (i.e. (4), (8), (9) and (19) are not ignorable issue. I think)
>
> I'm guessing most of the existing solutions get away with
> approximations and soft limits because they're mostly used on UMA
> embedded machines.
>
> But yes, we need to do better here.

Hm. If you want vmevent makes depend on CONFIG_EMBEDDED, I have no reason to
complain this feature. At that world, almost all applications _know_ their
system configuration. then I don't think api misuse issue is big matter.





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