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
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 [email protected]. 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:"[email protected]"> [email protected] </a>
>
--
Kind regards,
Minchan Kim
On Thu, May 3, 2012 at 10:57 AM, Minchan Kim <[email protected]> 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?
On 05/03/2012 05:07 PM, Pekka Enberg wrote:
> On Thu, May 3, 2012 at 10:57 AM, Minchan Kim <[email protected]> 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 [email protected]. 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:"[email protected]"> [email protected] </a>
>
--
Kind regards,
Minchan Kim