On Thu, 21 May 2009 19:36:06 +0900 (JST) Ryo Tsuruta <ryov@xxxxxxxxxxxxx> wrote: > Hi Kamezawa-san and Kosaki-san, > > > > I have a suggestion for css_id numbering. How about using the same > > > numbering scheme as process ID for css_id instead of idr? It prevents > > > the same ID from being reused quickly. > > > > process ID is not "short"(2bytes). > > > > > blkio-cgroup can benefit from it. If some pages still have an old ID, > > > it can somewhat prevents IOs associated with those pages from being > > > charged for a new cgroup which are reusing the old ID. > > > > plz see memcg's code. no reuse if id is still used. > > blkio-cgroup embeds css_id into page_cgroup->flags, and the ID in the > flags still remain even after the cgroup which marks up the page is > removed. > > The current numbering scheme of css_id choose the lowest number from > available IDs. When a cgroup is created right after another cgroup is > removed (no one referes to the cgroup), the same number will be reused > for the new cgroup. > > When an IO associated with the page is issued, an IO controller which > uses blkio-cgroup charges the new cgroup according to the ID in the > page_cgroup->flags, instead of the removed cgroup. If css_id is simply > incremented by one like process ID, I think we could avoid such wrong > charges in many cases. > IDR uses structure lika a radix-tree and it's important to keep the range as small as possible. And scheme like PID will have reuse issue anyway. 99.9% is not 100%. If 1023 of IDs are used under total 1024 IDS, you'll see reuse soon. please rewrite css_id by yourself if you have better codes than IDR. IIUC, it's keeps footprint small. > > it seems bogus solusion. > > pid rule also can make conflict. I think blkio-cgroup should be fixed. > > This solution is reasonable for accuracy, even conflicts occur. > I think keeping down the overhead of blkio-cgroup is more important. > please use private refcnt for avoiding reuse. It's the only way to prevent reuse of ID in theory. Thanks, -Kame _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
