vmevent: Use 'struct vmevent_attr' for vmevent_fd() ABI
PATCH 1/1 vmevent: Use 'struct vmevent_attr' for vmevent_fd() ABI
This patch introduces 'struct vmevent_attr' and converts the vmevent_fd() ABI to use it which makes the ABI much more flexible.
--- include/linux/vmevent.h | 66 +++++++++---- mm/vmevent.c | 186 +++++++++++++++++++++++----------- tools/testing/vmevent/vmevent-test.c | 54 +++++++--- 3 files changed, 212 insertions(+), 94 deletions(-)
include/linux/vmevent.h +48 -18
@@ -3,53 +3,83 @@#include <linux/types.h> +/* +* Types of memory attributes which could be monitored through vmevent API +*/ enum { -VMEVENT_TYPE_FREE_THRESHOLD =1ULL <<0 , -VMEVENT_TYPE_SAMPLE =1ULL <<1 , +VMEVENT_ATTR_NR_AVAIL_PAGES =1UL , +VMEVENT_ATTR_NR_FREE_PAGES =2UL , +VMEVENT_ATTR_NR_SWAP_PAGES =3UL , + +VMEVENT_ATTR_MAX /* non-ABI */ }; +/* +* Attribute state bits for threshold +*/ enum { -VMEVENT_EATTR_NR_AVAIL_PAGES =1ULL <<0 , -VMEVENT_EATTR_NR_FREE_PAGES =1ULL <<1 , -VMEVENT_EATTR_NR_SWAP_PAGES =1ULL <<2 , +/* +* Sample value is less than user-specified value +*/ +VMEVENT_ATTR_STATE_VALUE_LT = (1UL <<0 ), }; -struct vmevent_config { +struct vmevent_attr {/* -* Size of the struct for ABI extensibility. +* Value in pages delivered with pointed attribute */ -__u32 size; +__u64 value;/* -* Notification type bitmask +* Type of profiled attribute from VMEVENT_ATTR_XXX */ -__u64 type; +__u32 type; + +/* +* Bitmask of current attribute value (see VMEVENT_ATTR_STATE_XXX) +*/ +__u32 state; +}; +#define VMEVENT_CONFIG_MAX_ATTRS 32 + +/* +* Configuration structure to get notifications and attributes values +*/ +struct vmevent_config {/* -* Attributes that are delivered as part of events. +* Size of the struct for ABI extensibility. */ -__u64 event_attrs; +__u32 size;/* -* Threshold of free pages in the system. +* Counter of number monitored attributes */ -__u32 free_pages_threshold; +__u32 counter;/* * Sample period in nanoseconds */ __u64 sample_period_ns; + +/* +* Attributes that are monitored and delivered as part of events +*/ +struct vmevent_attr attrs[VMEVENT_CONFIG_MAX_ATTRS ]; };struct vmevent_event {/* -* Size of the struct for ABI extensibility. +* Counter of attributes in this VM event */ -__u32 size; +__u32 counter; -__u64 attrs; +__u32 padding; -__u64 attr_values[]; +/* +* Attributes for this VM event +*/ +struct vmevent_attr attrs[]; };#endif /* _LINUX_VMEVENT_H */
mm/vmevent.c +126 -60
267 lines not on this page · raw message
tools/testing/vmevent/vmevent-test.c +38 -16
75 lines not on this page · raw message
Signature · 1 line
1.7.6.5
Quoted 8 lines · Pekka Enberg
This patch introduces 'struct
vmevent_attr' and converts thevmevent_fd()ABI to use it which makes the ABI much more flexible.Originally-by Leonid Moiseichuk <[email protected]>Cc David Rientjes <[email protected]>Cc Anton Vorontsov <[email protected]>Signed-off-by Pekka Enberg <[email protected]>---
Sorry for hijacking this thread, but speaking of big changes. Are there any plans or ideas to add other methods of sampling, i.e. something not timer-based?
I like how it's done for cgroups, i.e. via rate-limited events (and the events are "page alloc/free").
But doing this cgroup-way would probably dismiss the point of "lightweight" notifications.
Though, current vmevent seems not so lightweigh in sense of battery usage and accuracy (i.e. how quick we're able to detect the crossed threshold). To get better accuracy we would need to run timer at higher frequencies, but then we would waste more battery.
Sure, vmevent is still lightweight in sense that it does not cause much runtime overhead or memory wastage (unlike cgroups).
The only idea I have for vmevent is to make some hybrid: timer plus shrinker API. That way we would detect "low memory" events fast enough via shrinker API, and thus run timer at low freq.
But we would still have a running timer, which would wake up a system periodically, which is still quite bad. :-/
Thanks,
Signature · 2 lines
Anton Vorontsov Email: [email protected]
Quoted 5 lines
-----Original Message-----
From: ext Anton Vorontsov [mailto:[email protected]]
Sent: 07 March, 2012 01:00
To: Pekka Enberg
Cc: [email protected]; Moiseichuk Leonid (Nokia-MP/Espoo);
...
Quoted 3 lines
Sorry for hijacking this thread, but speaking of big changes. Are there any plans or ideas to add other methods of sampling, i.e. something not timer- based?
...
Quoted 4 lines
Though, current vmevent seems not so lightweigh in sense of battery usage and accuracy (i.e. how quick we're able to detect the crossed threshold). To get better accuracy we would need to run timer at higher frequencies, but then we would waste more battery.
One of patch I sent was about switching to deferred timer. This API should not be 100% accurate first, and using deferred timers will allow to sleep properly when system has no activity. I hope Pekka will accept the next patch as well.
Quoted 3 lines
Sure, vmevent is still lightweight in sense that it does not cause much runtime overhead or memory wastage (unlike cgroups).
"Timer work" is really lightweight.
Quoted 4 lines
The only idea I have for vmevent is to make some hybrid: timer plus shrinker API. That way we would detect "low memory" events fast enough via shrinker API, and thus run timer at low freq.
I used the same, see post about memnotify. Shrinker roll timer to be triggered soon.
���{.n�+�������+%�����ݶ��w��{.n�+����{��G�����{ay� ʇڙ�,j��f���h��������z_�(�階�ݢj"���m������G������?����&���~��iO��z��v�^�m���� ������?�I�
Quoted 9 lines · On Wed, 7 Mar 2012, [email protected] wrote:
Quoted 5 lines
-----Original Message-----
From: ext Anton Vorontsov [mailto:[email protected]]
Sent: 07 March, 2012 01:00
To: Pekka Enberg
Cc: [email protected]; Moiseichuk Leonid (Nokia-MP/Espoo);...
Quoted 3 lines
Sorry for hijacking this thread, but speaking of big changes. Are there any plans or ideas to add other methods of sampling, i.e. something not timer- based?
Quoted 8 lines
...
Quoted 4 lines
Though, current vmevent seems not so lightweigh in sense of battery usage and accuracy (i.e. how quick we're able to detect the crossed threshold). To get better accuracy we would need to run timer at higher frequencies, but then we would waste more battery.
One of patch I sent was about switching to deferred timer. This API should not be 100% accurate first, and using deferred timers will allow to sleep properly when system has no activity. I hope Pekka will accept the next patch as well.
I merged that patch yesterday:
Pekka
Quoted 9 lines · On Wed, Mar 07, 2012 at 07:53:37AM +0000, [email protected] wrote:
Quoted 5 lines
-----Original Message-----
From: ext Anton Vorontsov [mailto:[email protected]]
Sent: 07 March, 2012 01:00
To: Pekka Enberg
Cc: [email protected]; Moiseichuk Leonid (Nokia-MP/Espoo);...
Quoted 3 lines
Sorry for hijacking this thread, but speaking of big changes. Are there any plans or ideas to add other methods of sampling, i.e. something not timer- based?
Quoted 8 lines
...
Quoted 4 lines
Though, current vmevent seems not so lightweigh in sense of battery usage and accuracy (i.e. how quick we're able to detect the crossed threshold). To get better accuracy we would need to run timer at higher frequencies, but then we would waste more battery.
One of patch I sent was about switching to deferred timer. This API should not be 100% accurate first, and using deferred timers will allow to sleep properly when system has no activity. I hope Pekka will accept the next patch as well.
Nice idea!
Thanks,
Signature · 2 lines
Anton Vorontsov Email: [email protected]
Quoted 3 lines · Anton Vorontsov
Sorry for hijacking this thread, but speaking of big changes. Are there any plans or ideas to add other methods of sampling, i.e. something not timer-based?
Yes and no.
Linux already has non-timer based "vm events" via tracepoints. There's absolutely no need to reinvent the wheel so we should integrate with perf more closely.
The biggest open question is whether or not a new syscall is needed for configuring memory thresholds and such.
Pekka