[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4FA23E47.6040303@kernel.org>
Date: Thu, 03 May 2012 17:13:59 +0900
From: Minchan Kim <minchan@...nel.org>
To: Pekka Enberg <penberg@...nel.org>
CC: linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>,
Anton Vorontsov <anton.vorontsov@...aro.org>,
Leonid Moiseichuk <leonid.moiseichuk@...ia.com>
Subject: Re: vmevent: question?
On 05/03/2012 05:07 PM, Pekka Enberg wrote:
> On Thu, May 3, 2012 at 10:57 AM, Minchan Kim <minchan@...nel.org> 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@...ck.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@...ck.org"> email@...ck.org </a>
>
--
Kind regards,
Minchan Kim
--
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/
Powered by blists - more mailing lists