From: Minchan Kim <minchan@kernel.org> To: Pekka Enberg <penberg@kernel.org> Cc: linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>, Anton Vorontsov <anton.vorontsov@linaro.org>, Leonid Moiseichuk <leonid.moiseichuk@nokia.com> Subject: Re: vmevent: question? Date: Thu, 03 May 2012 16:57:55 +0900 [thread overview] Message-ID: <4FA23A83.4040604@kernel.org> (raw) In-Reply-To: <alpine.LFD.2.02.1205031019410.3686@tux.localdomain> On 05/03/2012 04:24 PM, Pekka Enberg wrote: > On Mon, 30 Apr 2012, Minchan Kim wrote: >>> What kind of consistency guarantees do you mean? The data sent to >>> userspace is always a snapshot of the state and therefore can be stale >>> by the time it reaches userspace. >> >> Consistency between component of snapshot. >> let's assume following as >> >> 1. User expect some events's value would be minus when event he expect happen. >> A : -3, B : -4, C : -5, D : -6 >> 2. Logically, it's not possible to mix plus and minus values for the events. >> A : -3, B : -4, C : -5, D : -6 ( O ) >> A : -3, B : -4, C : 1, D : 2 ( X ) >> >> But in current implementation, some of those could be minus and some of those could be plus. >> Which event could user believe? >> At least, we need a _captured_ value when event triggered so that user can ignore other values. > > Sorry, I still don't quite understand the problem. Sorry for my poor explanation. My point is when userspace get vmevent_event by reading fd, it could enumerate several attribute all at once. Then, one of attribute(call A) made by vmevent_match in kernel and other attributes(call B, C, D) are just extra for convenience. Because there is time gap when kernel get attribute values, B,C,D could be stale. Then, how can user determine which event is really triggered? A or B or C or D? Which event really happens? > > The current implementation provides the same kind of snapshot consistency > as reading from /proc/vmstat does (modulo the fact that we read them > twice) for the values we support. > > Pekka > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> > -- Kind regards, Minchan Kim
WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org> To: Pekka Enberg <penberg@kernel.org> Cc: linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>, Anton Vorontsov <anton.vorontsov@linaro.org>, Leonid Moiseichuk <leonid.moiseichuk@nokia.com> Subject: Re: vmevent: question? Date: Thu, 03 May 2012 16:57:55 +0900 [thread overview] Message-ID: <4FA23A83.4040604@kernel.org> (raw) In-Reply-To: <alpine.LFD.2.02.1205031019410.3686@tux.localdomain> On 05/03/2012 04:24 PM, Pekka Enberg wrote: > On Mon, 30 Apr 2012, Minchan Kim wrote: >>> What kind of consistency guarantees do you mean? The data sent to >>> userspace is always a snapshot of the state and therefore can be stale >>> by the time it reaches userspace. >> >> Consistency between component of snapshot. >> let's assume following as >> >> 1. User expect some events's value would be minus when event he expect happen. >> A : -3, B : -4, C : -5, D : -6 >> 2. Logically, it's not possible to mix plus and minus values for the events. >> A : -3, B : -4, C : -5, D : -6 ( O ) >> A : -3, B : -4, C : 1, D : 2 ( X ) >> >> But in current implementation, some of those could be minus and some of those could be plus. >> Which event could user believe? >> At least, we need a _captured_ value when event triggered so that user can ignore other values. > > Sorry, I still don't quite understand the problem. Sorry for my poor explanation. My point is when userspace get vmevent_event by reading fd, it could enumerate several attribute all at once. Then, one of attribute(call A) made by vmevent_match in kernel and other attributes(call B, C, D) are just extra for convenience. Because there is time gap when kernel get attribute values, B,C,D could be stale. Then, how can user determine which event is really triggered? A or B or C or D? Which event really happens? > > The current implementation provides the same kind of snapshot consistency > as reading from /proc/vmstat does (modulo the fact that we read them > twice) for the values we support. > > Pekka > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> > -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-05-03 7:57 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-04-30 7:06 vmevent: question? Minchan Kim 2012-04-30 7:06 ` Minchan Kim 2012-04-30 7:35 ` Pekka Enberg 2012-04-30 7:35 ` Pekka Enberg 2012-04-30 7:52 ` Minchan Kim 2012-04-30 7:52 ` Minchan Kim 2012-04-30 8:01 ` Pekka Enberg 2012-04-30 8:01 ` Pekka Enberg 2012-04-30 8:36 ` Minchan Kim 2012-04-30 8:36 ` Minchan Kim 2012-05-03 7:24 ` Pekka Enberg 2012-05-03 7:24 ` Pekka Enberg 2012-05-03 7:57 ` Minchan Kim [this message] 2012-05-03 7:57 ` Minchan Kim 2012-05-03 8:07 ` Pekka Enberg 2012-05-03 8:07 ` Pekka Enberg 2012-05-03 8:13 ` Minchan Kim 2012-05-03 8:13 ` Minchan Kim 2012-04-30 7:54 ` Anton Vorontsov 2012-04-30 7:54 ` Anton Vorontsov 2012-04-30 8:03 ` Pekka Enberg 2012-04-30 8:03 ` Pekka Enberg
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4FA23A83.4040604@kernel.org \ --to=minchan@kernel.org \ --cc=anton.vorontsov@linaro.org \ --cc=leonid.moiseichuk@nokia.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mingo@elte.hu \ --cc=penberg@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.