From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx184.postini.com [74.125.245.184]) by kanga.kvack.org (Postfix) with SMTP id 5A9A36B0044 for ; Mon, 30 Apr 2012 03:06:26 -0400 (EDT) Message-ID: <4F9E39F1.5030600@kernel.org> Date: Mon, 30 Apr 2012 16:06:25 +0900 From: Minchan Kim MIME-Version: 1.0 Subject: vmevent: question? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Pekka Enberg , linux-mm@kvack.org, LKML Hi Pekka, I looked into vmevent and have few questions. vmevent_smaple gathers all registered values to report to user if vmevent match. But the time gap between vmevent match check and vmevent_sample_attr could make error so user could confuse. Q 1. Why do we report _all_ registered vmstat value? In my opinion, it's okay just to report _a_ value vmevent_match happens. Q 2. Is it okay although value when vmevent_match check happens is different with vmevent_sample_attr in vmevent_sample's for loop? I think it's not good. Q 3. Do you have any plan to change getting value's method? Now it's IRQ context so we have limitation to get a vmstat values so that It couldn't be generic. IMHO, To merge into mainline, we should solve this problem. Q 4. Do you have any plan for this patchset to merge into mainline? Thanks. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx126.postini.com [74.125.245.126]) by kanga.kvack.org (Postfix) with SMTP id 95DC26B0044 for ; Mon, 30 Apr 2012 03:35:03 -0400 (EDT) Received: by iajr24 with SMTP id r24so5648228iaj.14 for ; Mon, 30 Apr 2012 00:35:02 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4F9E39F1.5030600@kernel.org> References: <4F9E39F1.5030600@kernel.org> Date: Mon, 30 Apr 2012 10:35:02 +0300 Message-ID: Subject: Re: vmevent: question? From: Pekka Enberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: linux-mm@kvack.org, LKML , Ingo Molnar , Anton Vorontsov , Leonid Moiseichuk Hi Minchan, On Mon, Apr 30, 2012 at 10:06 AM, Minchan Kim wrote: > vmevent_smaple gathers all registered values to report to user if vmevent= match. > But the time gap between vmevent match check and vmevent_sample_attr coul= d make error > so user could confuse. > > Q 1. Why do we report _all_ registered vmstat value? > =A0 =A0 In my opinion, it's okay just to report _a_ value vmevent_match h= appens. It makes the userspace side simpler for "lowmem notification" use case. I'm open to changing the ABI if it doesn't make the userspace side too complex. > Q 2. Is it okay although value when vmevent_match check happens is differ= ent with > =A0 =A0 vmevent_sample_attr in vmevent_sample's for loop? > =A0 =A0 I think it's not good. Yeah, that's just silly and needs fixing. > Q 3. Do you have any plan to change getting value's method? > =A0 =A0 Now it's IRQ context so we have limitation to get a vmstat values= so that > =A0 =A0 It couldn't be generic. IMHO, To merge into mainline, we should s= olve this problem. Yes, that needs fixing as well. I was hoping to reuse perf sampling code for this. > Q 4. Do you have any plan for this patchset to merge into mainline? Yes, I'm interested in pushing it forward if we can show that the ABI makes sense, is stable and generic enough, and fixes real world problems. 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx137.postini.com [74.125.245.137]) by kanga.kvack.org (Postfix) with SMTP id 863ED6B0044 for ; Mon, 30 Apr 2012 03:52:16 -0400 (EDT) Message-ID: <4F9E44AD.8020701@kernel.org> Date: Mon, 30 Apr 2012 16:52:13 +0900 From: Minchan Kim MIME-Version: 1.0 Subject: Re: vmevent: question? References: <4F9E39F1.5030600@kernel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Pekka Enberg Cc: linux-mm@kvack.org, LKML , Ingo Molnar , Anton Vorontsov , Leonid Moiseichuk On 04/30/2012 04:35 PM, Pekka Enberg wrote: > Hi Minchan, > > On Mon, Apr 30, 2012 at 10:06 AM, Minchan Kim wrote: >> vmevent_smaple gathers all registered values to report to user if vmevent match. >> But the time gap between vmevent match check and vmevent_sample_attr could make error >> so user could confuse. >> >> Q 1. Why do we report _all_ registered vmstat value? >> In my opinion, it's okay just to report _a_ value vmevent_match happens. > > It makes the userspace side simpler for "lowmem notification" use > case. I'm open to changing the ABI if it doesn't make the userspace > side too complex. Yes. I understand your point but if we still consider all of values, we don't have any way to capture exact values except triggered event value. I mean there is no lock to keep consistency. If stale data is okay, no problem but IMHO, it could make user very confusing. So let's return value for first matched event if various event match. Of course, let's write down it in ABI. If there is other idea for reporting all of item with consistent, I'm okay. >> Q 2. Is it okay although value when vmevent_match check happens is different with >> vmevent_sample_attr in vmevent_sample's for loop? >> I think it's not good. > > Yeah, that's just silly and needs fixing. It depends on Q.1. So first of all, we have to determine Q 1's policy. > >> Q 3. Do you have any plan to change getting value's method? >> Now it's IRQ context so we have limitation to get a vmstat values so that >> It couldn't be generic. IMHO, To merge into mainline, we should solve this problem. > > Yes, that needs fixing as well. I was hoping to reuse perf sampling > code for this. > >> Q 4. Do you have any plan for this patchset to merge into mainline? > > Yes, I'm interested in pushing it forward if we can show that the ABI > makes sense, is stable and generic enough, and fixes real world > problems. Yes. I think it would be a good for embedded and KVM world for preventing unnecessary swapped-out and OOM. :) -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx119.postini.com [74.125.245.119]) by kanga.kvack.org (Postfix) with SMTP id E68006B0044 for ; Mon, 30 Apr 2012 03:55:38 -0400 (EDT) Received: by pbbrp2 with SMTP id rp2so1012621pbb.14 for ; Mon, 30 Apr 2012 00:55:38 -0700 (PDT) Date: Mon, 30 Apr 2012 00:54:18 -0700 From: Anton Vorontsov Subject: Re: vmevent: question? Message-ID: <20120430075417.GA8438@lizard> References: <4F9E39F1.5030600@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Pekka Enberg Cc: Minchan Kim , linux-mm@kvack.org, LKML , Ingo Molnar , Leonid Moiseichuk Hello Pekka, On Mon, Apr 30, 2012 at 10:35:02AM +0300, Pekka Enberg wrote: > > vmevent_smaple gathers all registered values to report to user if vmevent match. > > But the time gap between vmevent match check and vmevent_sample_attr could make error > > so user could confuse. > > > > Q 1. Why do we report _all_ registered vmstat value? > > A A In my opinion, it's okay just to report _a_ value vmevent_match happens. > > It makes the userspace side simpler for "lowmem notification" use > case. I'm open to changing the ABI if it doesn't make the userspace > side too complex. Yep. Actually, I'd like to add something like 'file_pages - shmem' attribute, and reporting both (i.e. this new attr and free_pages) values at the same time (even if just one crossed the threshold). Reporting all the values would help userspace logic (so it won't need to read /proc again). > > Q 4. Do you have any plan for this patchset to merge into mainline? > > Yes, I'm interested in pushing it forward if we can show that the ABI > makes sense, is stable and generic enough, and fixes real world > problems. It seems to be a pretty nice driver. Speaking of ABI, the only thing I personally dislike is VMEVENT_CONFIG_MAX_ATTRS (i.e. fixed-size array in vmevent_config)... but I guess it's pretty easy to make it variable-sized array... was there any particular reason to make the _MAX thing? Thanks! -- Anton Vorontsov Email: cbouatmailru@gmail.com -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx107.postini.com [74.125.245.107]) by kanga.kvack.org (Postfix) with SMTP id 023F16B0044 for ; Mon, 30 Apr 2012 04:01:40 -0400 (EDT) Received: by iajr24 with SMTP id r24so5683038iaj.14 for ; Mon, 30 Apr 2012 01:01:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4F9E44AD.8020701@kernel.org> References: <4F9E39F1.5030600@kernel.org> <4F9E44AD.8020701@kernel.org> Date: Mon, 30 Apr 2012 11:01:40 +0300 Message-ID: Subject: Re: vmevent: question? From: Pekka Enberg Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: linux-mm@kvack.org, LKML , Ingo Molnar , Anton Vorontsov , Leonid Moiseichuk Hi Minchan, On Mon, Apr 30, 2012 at 10:52 AM, Minchan Kim wrote: >> It makes the userspace side simpler for "lowmem notification" use >> case. I'm open to changing the ABI if it doesn't make the userspace >> side too complex. > > Yes. I understand your point but if we still consider all of values, > we don't have any way to capture exact values except triggered event value. > I mean there is no lock to keep consistency. > If stale data is okay, no problem but IMHO, it could make user very confusing. > So let's return value for first matched event if various event match. > Of course, let's write down it in ABI. > If there is other idea for reporting all of item with consistent, I'm okay. 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. If your code needs stricter consistency guarantees, you probably want to do it in the kernel. 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx114.postini.com [74.125.245.114]) by kanga.kvack.org (Postfix) with SMTP id 031226B0044 for ; Mon, 30 Apr 2012 04:03:23 -0400 (EDT) Received: by iajr24 with SMTP id r24so5685574iaj.14 for ; Mon, 30 Apr 2012 01:03:23 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20120430075417.GA8438@lizard> References: <4F9E39F1.5030600@kernel.org> <20120430075417.GA8438@lizard> Date: Mon, 30 Apr 2012 11:03:23 +0300 Message-ID: Subject: Re: vmevent: question? From: Pekka Enberg Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Anton Vorontsov Cc: Minchan Kim , linux-mm@kvack.org, LKML , Ingo Molnar , Leonid Moiseichuk Hi Anton, On Mon, Apr 30, 2012 at 10:54 AM, Anton Vorontsov wrote: > It seems to be a pretty nice driver. Speaking of ABI, the only thing > I personally dislike is VMEVENT_CONFIG_MAX_ATTRS (i.e. fixed-size > array in vmevent_config)... but I guess it's pretty easy to make > it variable-sized array... was there any particular reason to make > the _MAX thing? It made the implementation simpler but the ABI should support variable-sized arrays. We can relax the limitation if necessary. 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx162.postini.com [74.125.245.162]) by kanga.kvack.org (Postfix) with SMTP id 434046B0044 for ; Mon, 30 Apr 2012 04:36:29 -0400 (EDT) Message-ID: <4F9E4F0A.8030900@kernel.org> Date: Mon, 30 Apr 2012 17:36:26 +0900 From: Minchan Kim MIME-Version: 1.0 Subject: Re: vmevent: question? References: <4F9E39F1.5030600@kernel.org> <4F9E44AD.8020701@kernel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Pekka Enberg Cc: linux-mm@kvack.org, LKML , Ingo Molnar , Anton Vorontsov , Leonid Moiseichuk On 04/30/2012 05:01 PM, Pekka Enberg wrote: > Hi Minchan, > > On Mon, Apr 30, 2012 at 10:52 AM, Minchan Kim wrote: >>> It makes the userspace side simpler for "lowmem notification" use >>> case. I'm open to changing the ABI if it doesn't make the userspace >>> side too complex. >> >> Yes. I understand your point but if we still consider all of values, >> we don't have any way to capture exact values except triggered event value. >> I mean there is no lock to keep consistency. >> If stale data is okay, no problem but IMHO, it could make user very confusing. >> So let's return value for first matched event if various event match. >> Of course, let's write down it in ABI. >> If there is other idea for reporting all of item with consistent, I'm okay. > > 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. > > If your code needs stricter consistency guarantees, you probably want > to do it in the kernel. > > 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: email@kvack.org > -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx167.postini.com [74.125.245.167]) by kanga.kvack.org (Postfix) with SMTP id D7D3C6B0083 for ; Thu, 3 May 2012 03:24:47 -0400 (EDT) Received: by lagz14 with SMTP id z14so1496035lag.14 for ; Thu, 03 May 2012 00:24:45 -0700 (PDT) Date: Thu, 3 May 2012 10:24:42 +0300 (EEST) From: Pekka Enberg Subject: Re: vmevent: question? In-Reply-To: <4F9E4F0A.8030900@kernel.org> Message-ID: References: <4F9E39F1.5030600@kernel.org> <4F9E44AD.8020701@kernel.org> <4F9E4F0A.8030900@kernel.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: linux-mm@kvack.org, LKML , Ingo Molnar , Anton Vorontsov , Leonid Moiseichuk 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. 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx189.postini.com [74.125.245.189]) by kanga.kvack.org (Postfix) with SMTP id B85E96B004D for ; Thu, 3 May 2012 03:57:56 -0400 (EDT) Message-ID: <4FA23A83.4040604@kernel.org> Date: Thu, 03 May 2012 16:57:55 +0900 From: Minchan Kim MIME-Version: 1.0 Subject: Re: vmevent: question? References: <4F9E39F1.5030600@kernel.org> <4F9E44AD.8020701@kernel.org> <4F9E4F0A.8030900@kernel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Pekka Enberg Cc: linux-mm@kvack.org, LKML , Ingo Molnar , Anton Vorontsov , Leonid Moiseichuk 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: email@kvack.org > -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx196.postini.com [74.125.245.196]) by kanga.kvack.org (Postfix) with SMTP id D7D7D6B004D for ; Thu, 3 May 2012 04:07:48 -0400 (EDT) Received: by ggeq1 with SMTP id q1so242220gge.14 for ; Thu, 03 May 2012 01:07:48 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4FA23A83.4040604@kernel.org> References: <4F9E39F1.5030600@kernel.org> <4F9E44AD.8020701@kernel.org> <4F9E4F0A.8030900@kernel.org> <4FA23A83.4040604@kernel.org> Date: Thu, 3 May 2012 11:07:47 +0300 Message-ID: Subject: Re: vmevent: question? From: Pekka Enberg Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: linux-mm@kvack.org, LKML , Ingo Molnar , Anton Vorontsov , Leonid Moiseichuk On Thu, May 3, 2012 at 10:57 AM, Minchan Kim wrote: > 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? Right. Mark the matching values with something like VMEVENT_ATTR_STATE_CAPTURED should be sufficient? -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx188.postini.com [74.125.245.188]) by kanga.kvack.org (Postfix) with SMTP id 2F2216B004D for ; Thu, 3 May 2012 04:14:12 -0400 (EDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SPrAv-00010C-3c for linux-mm@kvack.org; Thu, 03 May 2012 10:14:09 +0200 Received: from 121.50.20.41 ([121.50.20.41]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 May 2012 10:14:08 +0200 Received: from minchan by 121.50.20.41 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 May 2012 10:14:08 +0200 From: Minchan Kim Subject: Re: vmevent: question? Date: Thu, 03 May 2012 17:13:59 +0900 Message-ID: <4FA23E47.6040303@kernel.org> References: <4F9E39F1.5030600@kernel.org> <4F9E44AD.8020701@kernel.org> <4F9E4F0A.8030900@kernel.org> <4FA23A83.4040604@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org On 05/03/2012 05:07 PM, Pekka Enberg wrote: > On Thu, May 3, 2012 at 10:57 AM, Minchan Kim wrote: >> 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? > > Right. Mark the matching values with something like > VMEVENT_ATTR_STATE_CAPTURED should be sufficient? Seems to be good and we have to notice to user by document "Except VMEVENT_ATTR_STATE_CAPTURED, all attributes's value could be stale. So, don't be deceived. Please ignore if you need" First of all, let make CAPTURED state could be exact. ----- > Q 2. Is it okay although value when vmevent_match check happens is different with > vmevent_sample_attr in vmevent_sample's for loop? > I think it's not good. Yeah, that's just silly and needs fixing. ----- > > -- > 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: email@kvack.org > -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754819Ab2D3HG1 (ORCPT ); Mon, 30 Apr 2012 03:06:27 -0400 Received: from LGEMRELSE1Q.lge.com ([156.147.1.111]:57482 "EHLO LGEMRELSE1Q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751609Ab2D3HG0 (ORCPT ); Mon, 30 Apr 2012 03:06:26 -0400 X-AuditID: 9c93016f-b7cfcae00000449e-97-4f9e39f009ee Message-ID: <4F9E39F1.5030600@kernel.org> Date: Mon, 30 Apr 2012 16:06:25 +0900 From: Minchan Kim User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Pekka Enberg , linux-mm@kvack.org, LKML Subject: vmevent: question? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Pekka, I looked into vmevent and have few questions. vmevent_smaple gathers all registered values to report to user if vmevent match. But the time gap between vmevent match check and vmevent_sample_attr could make error so user could confuse. Q 1. Why do we report _all_ registered vmstat value? In my opinion, it's okay just to report _a_ value vmevent_match happens. Q 2. Is it okay although value when vmevent_match check happens is different with vmevent_sample_attr in vmevent_sample's for loop? I think it's not good. Q 3. Do you have any plan to change getting value's method? Now it's IRQ context so we have limitation to get a vmstat values so that It couldn't be generic. IMHO, To merge into mainline, we should solve this problem. Q 4. Do you have any plan for this patchset to merge into mainline? Thanks. -- Kind regards, Minchan Kim From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752043Ab2D3HfF (ORCPT ); Mon, 30 Apr 2012 03:35:05 -0400 Received: from mail-iy0-f174.google.com ([209.85.210.174]:33013 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751803Ab2D3HfD convert rfc822-to-8bit (ORCPT ); Mon, 30 Apr 2012 03:35:03 -0400 MIME-Version: 1.0 In-Reply-To: <4F9E39F1.5030600@kernel.org> References: <4F9E39F1.5030600@kernel.org> Date: Mon, 30 Apr 2012 10:35:02 +0300 X-Google-Sender-Auth: riqg2vxqEWplZ2pPLIrcI5Dj9Zs Message-ID: Subject: Re: vmevent: question? From: Pekka Enberg To: Minchan Kim Cc: linux-mm@kvack.org, LKML , Ingo Molnar , Anton Vorontsov , Leonid Moiseichuk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Minchan, On Mon, Apr 30, 2012 at 10:06 AM, Minchan Kim wrote: > vmevent_smaple gathers all registered values to report to user if vmevent match. > But the time gap between vmevent match check and vmevent_sample_attr could make error > so user could confuse. > > Q 1. Why do we report _all_ registered vmstat value? >     In my opinion, it's okay just to report _a_ value vmevent_match happens. It makes the userspace side simpler for "lowmem notification" use case. I'm open to changing the ABI if it doesn't make the userspace side too complex. > Q 2. Is it okay although value when vmevent_match check happens is different with >     vmevent_sample_attr in vmevent_sample's for loop? >     I think it's not good. Yeah, that's just silly and needs fixing. > Q 3. Do you have any plan to change getting value's method? >     Now it's IRQ context so we have limitation to get a vmstat values so that >     It couldn't be generic. IMHO, To merge into mainline, we should solve this problem. Yes, that needs fixing as well. I was hoping to reuse perf sampling code for this. > Q 4. Do you have any plan for this patchset to merge into mainline? Yes, I'm interested in pushing it forward if we can show that the ABI makes sense, is stable and generic enough, and fixes real world problems. Pekka From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752619Ab2D3HwS (ORCPT ); Mon, 30 Apr 2012 03:52:18 -0400 Received: from LGEMRELSE6Q.lge.com ([156.147.1.121]:64925 "EHLO LGEMRELSE6Q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751686Ab2D3HwR (ORCPT ); Mon, 30 Apr 2012 03:52:17 -0400 X-AuditID: 9c930179-b7bfaae000006f69-61-4f9e44ae581c Message-ID: <4F9E44AD.8020701@kernel.org> Date: Mon, 30 Apr 2012 16:52:13 +0900 From: Minchan Kim User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 Newsgroups: gmane.linux.kernel.mm,gmane.linux.kernel To: Pekka Enberg CC: linux-mm@kvack.org, LKML , Ingo Molnar , Anton Vorontsov , Leonid Moiseichuk Subject: Re: vmevent: question? References: <4F9E39F1.5030600@kernel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/30/2012 04:35 PM, Pekka Enberg wrote: > Hi Minchan, > > On Mon, Apr 30, 2012 at 10:06 AM, Minchan Kim wrote: >> vmevent_smaple gathers all registered values to report to user if vmevent match. >> But the time gap between vmevent match check and vmevent_sample_attr could make error >> so user could confuse. >> >> Q 1. Why do we report _all_ registered vmstat value? >> In my opinion, it's okay just to report _a_ value vmevent_match happens. > > It makes the userspace side simpler for "lowmem notification" use > case. I'm open to changing the ABI if it doesn't make the userspace > side too complex. Yes. I understand your point but if we still consider all of values, we don't have any way to capture exact values except triggered event value. I mean there is no lock to keep consistency. If stale data is okay, no problem but IMHO, it could make user very confusing. So let's return value for first matched event if various event match. Of course, let's write down it in ABI. If there is other idea for reporting all of item with consistent, I'm okay. >> Q 2. Is it okay although value when vmevent_match check happens is different with >> vmevent_sample_attr in vmevent_sample's for loop? >> I think it's not good. > > Yeah, that's just silly and needs fixing. It depends on Q.1. So first of all, we have to determine Q 1's policy. > >> Q 3. Do you have any plan to change getting value's method? >> Now it's IRQ context so we have limitation to get a vmstat values so that >> It couldn't be generic. IMHO, To merge into mainline, we should solve this problem. > > Yes, that needs fixing as well. I was hoping to reuse perf sampling > code for this. > >> Q 4. Do you have any plan for this patchset to merge into mainline? > > Yes, I'm interested in pushing it forward if we can show that the ABI > makes sense, is stable and generic enough, and fixes real world > problems. Yes. I think it would be a good for embedded and KVM world for preventing unnecessary swapped-out and OOM. :) -- Kind regards, Minchan Kim From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752891Ab2D3Hzj (ORCPT ); Mon, 30 Apr 2012 03:55:39 -0400 Received: from mail-pz0-f51.google.com ([209.85.210.51]:53788 "EHLO mail-pz0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751686Ab2D3Hzi (ORCPT ); Mon, 30 Apr 2012 03:55:38 -0400 Date: Mon, 30 Apr 2012 00:54:18 -0700 From: Anton Vorontsov To: Pekka Enberg Cc: Minchan Kim , linux-mm@kvack.org, LKML , Ingo Molnar , Leonid Moiseichuk Subject: Re: vmevent: question? Message-ID: <20120430075417.GA8438@lizard> References: <4F9E39F1.5030600@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Pekka, On Mon, Apr 30, 2012 at 10:35:02AM +0300, Pekka Enberg wrote: > > vmevent_smaple gathers all registered values to report to user if vmevent match. > > But the time gap between vmevent match check and vmevent_sample_attr could make error > > so user could confuse. > > > > Q 1. Why do we report _all_ registered vmstat value? > >     In my opinion, it's okay just to report _a_ value vmevent_match happens. > > It makes the userspace side simpler for "lowmem notification" use > case. I'm open to changing the ABI if it doesn't make the userspace > side too complex. Yep. Actually, I'd like to add something like 'file_pages - shmem' attribute, and reporting both (i.e. this new attr and free_pages) values at the same time (even if just one crossed the threshold). Reporting all the values would help userspace logic (so it won't need to read /proc again). > > Q 4. Do you have any plan for this patchset to merge into mainline? > > Yes, I'm interested in pushing it forward if we can show that the ABI > makes sense, is stable and generic enough, and fixes real world > problems. It seems to be a pretty nice driver. Speaking of ABI, the only thing I personally dislike is VMEVENT_CONFIG_MAX_ATTRS (i.e. fixed-size array in vmevent_config)... but I guess it's pretty easy to make it variable-sized array... was there any particular reason to make the _MAX thing? Thanks! -- Anton Vorontsov Email: cbouatmailru@gmail.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752839Ab2D3IBm (ORCPT ); Mon, 30 Apr 2012 04:01:42 -0400 Received: from mail-iy0-f174.google.com ([209.85.210.174]:38566 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751441Ab2D3IBl (ORCPT ); Mon, 30 Apr 2012 04:01:41 -0400 MIME-Version: 1.0 In-Reply-To: <4F9E44AD.8020701@kernel.org> References: <4F9E39F1.5030600@kernel.org> <4F9E44AD.8020701@kernel.org> Date: Mon, 30 Apr 2012 11:01:40 +0300 X-Google-Sender-Auth: 4DgnBQN3WAtJMv0MkHIqHt1UVJ4 Message-ID: Subject: Re: vmevent: question? From: Pekka Enberg To: Minchan Kim Cc: linux-mm@kvack.org, LKML , Ingo Molnar , Anton Vorontsov , Leonid Moiseichuk Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Minchan, On Mon, Apr 30, 2012 at 10:52 AM, Minchan Kim wrote: >> It makes the userspace side simpler for "lowmem notification" use >> case. I'm open to changing the ABI if it doesn't make the userspace >> side too complex. > > Yes. I understand your point but if we still consider all of values, > we don't have any way to capture exact values except triggered event value. > I mean there is no lock to keep consistency. > If stale data is okay, no problem but IMHO, it could make user very confusing. > So let's return value for first matched event if various event match. > Of course, let's write down it in ABI. > If there is other idea for reporting all of item with consistent, I'm okay. 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. If your code needs stricter consistency guarantees, you probably want to do it in the kernel. Pekka From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752891Ab2D3IDZ (ORCPT ); Mon, 30 Apr 2012 04:03:25 -0400 Received: from mail-iy0-f174.google.com ([209.85.210.174]:58152 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751791Ab2D3IDX (ORCPT ); Mon, 30 Apr 2012 04:03:23 -0400 MIME-Version: 1.0 In-Reply-To: <20120430075417.GA8438@lizard> References: <4F9E39F1.5030600@kernel.org> <20120430075417.GA8438@lizard> Date: Mon, 30 Apr 2012 11:03:23 +0300 X-Google-Sender-Auth: 0Nyz8IN4-QwDqVR80wBYsgJNVsI Message-ID: Subject: Re: vmevent: question? From: Pekka Enberg To: Anton Vorontsov Cc: Minchan Kim , linux-mm@kvack.org, LKML , Ingo Molnar , Leonid Moiseichuk Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Anton, On Mon, Apr 30, 2012 at 10:54 AM, Anton Vorontsov wrote: > It seems to be a pretty nice driver. Speaking of ABI, the only thing > I personally dislike is VMEVENT_CONFIG_MAX_ATTRS (i.e. fixed-size > array in vmevent_config)... but I guess it's pretty easy to make > it variable-sized array... was there any particular reason to make > the _MAX thing? It made the implementation simpler but the ABI should support variable-sized arrays. We can relax the limitation if necessary. Pekka From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755362Ab2D3Iga (ORCPT ); Mon, 30 Apr 2012 04:36:30 -0400 Received: from LGEMRELSE6Q.lge.com ([156.147.1.121]:50273 "EHLO LGEMRELSE6Q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753361Ab2D3Ig3 (ORCPT ); Mon, 30 Apr 2012 04:36:29 -0400 X-AuditID: 9c930179-b7bfaae000006f69-52-4f9e4f0b2ebf Message-ID: <4F9E4F0A.8030900@kernel.org> Date: Mon, 30 Apr 2012 17:36:26 +0900 From: Minchan Kim User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 Newsgroups: gmane.linux.kernel.mm,gmane.linux.kernel To: Pekka Enberg CC: linux-mm@kvack.org, LKML , Ingo Molnar , Anton Vorontsov , Leonid Moiseichuk Subject: Re: vmevent: question? References: <4F9E39F1.5030600@kernel.org> <4F9E44AD.8020701@kernel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/30/2012 05:01 PM, Pekka Enberg wrote: > Hi Minchan, > > On Mon, Apr 30, 2012 at 10:52 AM, Minchan Kim wrote: >>> It makes the userspace side simpler for "lowmem notification" use >>> case. I'm open to changing the ABI if it doesn't make the userspace >>> side too complex. >> >> Yes. I understand your point but if we still consider all of values, >> we don't have any way to capture exact values except triggered event value. >> I mean there is no lock to keep consistency. >> If stale data is okay, no problem but IMHO, it could make user very confusing. >> So let's return value for first matched event if various event match. >> Of course, let's write down it in ABI. >> If there is other idea for reporting all of item with consistent, I'm okay. > > 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. > > If your code needs stricter consistency guarantees, you probably want > to do it in the kernel. > > 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: email@kvack.org > -- Kind regards, Minchan Kim From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755671Ab2ECHYs (ORCPT ); Thu, 3 May 2012 03:24:48 -0400 Received: from mail-lpp01m010-f46.google.com ([209.85.215.46]:65422 "EHLO mail-lpp01m010-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752641Ab2ECHYr (ORCPT ); Thu, 3 May 2012 03:24:47 -0400 Date: Thu, 3 May 2012 10:24:42 +0300 (EEST) From: Pekka Enberg X-X-Sender: penberg@tux.localdomain To: Minchan Kim cc: linux-mm@kvack.org, LKML , Ingo Molnar , Anton Vorontsov , Leonid Moiseichuk Subject: Re: vmevent: question? In-Reply-To: <4F9E4F0A.8030900@kernel.org> Message-ID: References: <4F9E39F1.5030600@kernel.org> <4F9E44AD.8020701@kernel.org> <4F9E4F0A.8030900@kernel.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753877Ab2ECH57 (ORCPT ); Thu, 3 May 2012 03:57:59 -0400 Received: from LGEMRELSE7Q.lge.com ([156.147.1.151]:46717 "EHLO LGEMRELSE7Q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752643Ab2ECH56 (ORCPT ); Thu, 3 May 2012 03:57:58 -0400 X-AuditID: 9c930197-b7badae000000cfd-40-4fa23a8251c4 Message-ID: <4FA23A83.4040604@kernel.org> Date: Thu, 03 May 2012 16:57:55 +0900 From: Minchan Kim User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 Newsgroups: gmane.linux.kernel.mm,gmane.linux.kernel To: Pekka Enberg CC: linux-mm@kvack.org, LKML , Ingo Molnar , Anton Vorontsov , Leonid Moiseichuk Subject: Re: vmevent: question? References: <4F9E39F1.5030600@kernel.org> <4F9E44AD.8020701@kernel.org> <4F9E4F0A.8030900@kernel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: email@kvack.org > -- Kind regards, Minchan Kim From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754407Ab2ECIHv (ORCPT ); Thu, 3 May 2012 04:07:51 -0400 Received: from mail-gh0-f174.google.com ([209.85.160.174]:48526 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752482Ab2ECIHs (ORCPT ); Thu, 3 May 2012 04:07:48 -0400 MIME-Version: 1.0 In-Reply-To: <4FA23A83.4040604@kernel.org> References: <4F9E39F1.5030600@kernel.org> <4F9E44AD.8020701@kernel.org> <4F9E4F0A.8030900@kernel.org> <4FA23A83.4040604@kernel.org> Date: Thu, 3 May 2012 11:07:47 +0300 X-Google-Sender-Auth: G1vdFInBlZKSCDIiCcksveYL6xc Message-ID: Subject: Re: vmevent: question? From: Pekka Enberg To: Minchan Kim Cc: linux-mm@kvack.org, LKML , Ingo Molnar , Anton Vorontsov , Leonid Moiseichuk Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 3, 2012 at 10:57 AM, Minchan Kim wrote: > 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? Right. Mark the matching values with something like VMEVENT_ATTR_STATE_CAPTURED should be sufficient? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755431Ab2ECIOG (ORCPT ); Thu, 3 May 2012 04:14:06 -0400 Received: from LGEMRELSE1Q.lge.com ([156.147.1.111]:59444 "EHLO LGEMRELSE1Q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751593Ab2ECIOD (ORCPT ); Thu, 3 May 2012 04:14:03 -0400 X-AuditID: 9c93016f-b7c79ae0000006b3-9a-4fa23e482141 Message-ID: <4FA23E47.6040303@kernel.org> Date: Thu, 03 May 2012 17:13:59 +0900 From: Minchan Kim User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 Newsgroups: gmane.linux.kernel.mm,gmane.linux.kernel To: Pekka Enberg CC: linux-mm@kvack.org, LKML , Ingo Molnar , Anton Vorontsov , Leonid Moiseichuk Subject: Re: vmevent: question? References: <4F9E39F1.5030600@kernel.org> <4F9E44AD.8020701@kernel.org> <4F9E4F0A.8030900@kernel.org> <4FA23A83.4040604@kernel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/03/2012 05:07 PM, Pekka Enberg wrote: > On Thu, May 3, 2012 at 10:57 AM, Minchan Kim wrote: >> 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? > > Right. Mark the matching values with something like > VMEVENT_ATTR_STATE_CAPTURED should be sufficient? Seems to be good and we have to notice to user by document "Except VMEVENT_ATTR_STATE_CAPTURED, all attributes's value could be stale. So, don't be deceived. Please ignore if you need" First of all, let make CAPTURED state could be exact. ----- > Q 2. Is it okay although value when vmevent_match check happens is different with > vmevent_sample_attr in vmevent_sample's for loop? > I think it's not good. Yeah, that's just silly and needs fixing. ----- > > -- > 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: email@kvack.org > -- Kind regards, Minchan Kim