* Ken'ichi Ohmichi <[email protected]> [2009-05-07 15:17:17]:
>
> Hi Balbir,
>
> Thank you for the comment.
>
> Balbir Singh wrote:
> >> Changelog of v2:
> >> * Change only [PATCH 2/2] and there is not any changes in [PATCH 1/2].
> >> * Use clock_gettime(2) for getting timestamp since a system boot.
> >> * Change parent_info's memory to dynamic allocation.
> >>
> >> Hi,
> >>
> >> I have been testing a cgrulesengd daemon and I noticed it fails to
> >> change the cgroup of child occasionally. I tested it by following
> >> configulation file:
> >>
> >> /etc/cgrules.conf:
> >> user01 cpuset group01/user01
> >> % memory group01/user01
> >>
> >> A cpuset subsystem and a memory subsystem are mounted on different
> >> mount points, and a cgrulesengd daemon manages each subsystem.
> >> I login this environment as a user "user01", and each susbystem's
> >> tasks file is the following:
> >>
> >> # cat /mnt/cgroups/cpuset/group01/user01/tasks
> >> 31801
> >> 31805
> >> 31806
> >> #
> >> # cat /mnt/cgroups/memory/group01/user01/tasks
> >> 31801
> >> 31805
> >> #
> >> # pstree -p 32105
> >> sshd(31801)---sshd(31805)---bash(31806)
> >> #
> >>
> >> They should be the same, but they are different. I investigated this
> >> problem, and I found the cause. The reason is that the process(31806)
> >> was forked just after writing the process(31805) to a cpuset subsystem's
> >> tasks file:
> >>
> >> <1> The UID/GID CHANGE event of the process 31805 happens.
> >> <2> The daemon writes "31805" to a cpuset subsystem's tasks file.
> >> <3> The process 31806 is forked, and it appears on a cpuset subsystem's
> >> tasks file.
> >> <4> The daemon writes "31805" to a memory subsystem's tasks file.
> >> <5> The process 31806 does not appears on a memory subsystem's tasks file.
> >>
> >>
> >> For solving this problem, I propose the following sequence.
> >> 1. Store both the timestamp and the process-id when the step <4>.
> >> 2. If receiving a PROC_EVENT_FORK packet, check its parent-pid and its
> >> timestamp.
> >> 3. If its parent-pid and the stored process-id are same and its timestamp
> >> is older than the stored timestamp, change the cgroup of forked
> >> process.
> >>
> >
> > Hi, Ken'ichi
> >
> > The overall approach sounds right, however I am wondering why we don't
> > use the kernel timestamp and unique sequence number returned by proc
> > events. The sequence number is per CPU, but the timestamp present
> > should help us
> >
> > snippet of proc_event code for UID event notification
> >
> > ktime_get_ts(&ts); /* get high res monotonic timestamp */
> > put_unaligned(timespec_to_ns(&ts), (__u64*)&ev->timestamp_ns);
> >
> > Why do we need clock_gettime()?
>
> We need clock_gettime() for getting a timestamp when cgrulesengd daemon
> finished changing cgroup, because the daemon should notice a fork event
> happening while it changing cgroup.
>
> For example, I describe a UID event and a Fork event of this race problem
> in the following sequence table:
>
> In the following table,
> * TS means timestamp.
> * Pro-A means some process named A.
> * Pro-B means a process B which is a child of process A.
>
> TS | KERNEL | CGRULESENGD DAEMON
> ----+---------------------------+----------------------------------------
> 10 | Pro-A's UID event happen. |
> 20 | | Receive a UID event packet. (TS is 10)
> 30 | | Change Pro-A's cgroup of cpuset.
> 40 | Pro-A forks a new Pro-B. |
> 50 | | Change Pro-A's cgroup of memory.
> 60 | | [Store the pid of Pro-A and TS 60 by my
> patch]
> 70 | | Receive a FORK event packet. (TS is 40)
>
> On my patch,
> 1. (TS:60) A cgrulesengd daemon stores the pid of process A and the
> timestamp (60). *This timestamp is taken by clock_gettime().*
> 2. (TS:70) The daemon receives a FORK event packet, the daemon checks
> the parent pid and the timestamp (40). The daemon can know that a
> FORK event happened while the daemon changes the cgroup, because the
> timestamp (40) is older/smaller than the stored timestamp (60).
> So the daemon can change it into the correct cgroup.
>
> Does this answer your question ?
>
Yes, it does, Thanks!
>
> > Second question, when we queue all the timestamps, when do we free them?
> > Is the race window very small?
>
> We free old queued timestamps when recieving a new fork event in
> cgre_remove_old_parent_info().
Thanks, the patch is good to go.
--
Balbir
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Libcg-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libcg-devel
