On Tue, 18 Jan 2011 11:20:06 +0100 Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > On Tue, Jan 18, 2011 at 06:17:57PM +0900, KAMEZAWA Hiroyuki wrote: > > > > - I'm not sure PCG_MIGRATION. It's for avoiding races. > > > > > > That's also a scary patch... Yeah, it's to prevent uncharging of > > > oldpage in case migration fails and it has to be reused. I changed > > > the migration sequence for memcg a bit so that we don't have to do > > > that anymore. It survived basic testing. > > > > > > > Hmm. I saw level down of migration under memcg several times. So, I don't > > want to modify running one without enough reason. > > I guess all SECTION_BITS can be encoded to pc->flags without diet of flags. > > That's true, there is enough room for that. > > Those reduction patches I only wrote to also pack the pc->mem_cgroup > ID into pc->flags, but these are two independent problems. > That packing is dangerous because we have lock bit on pc->flags and some access to pc->mem_cgroup is lockless. IIUC, it's difficult to avoid race with modifying pc->mem_cgroup. Hm, if we remove PCG_ACCT_LRU, it may be possible but I'm not sure how FILESTAT etc. is safe. > I would not have finished the patch only for that one tiny flag, but > it actually saved code and made it IMO a bit easier to understand. I > consider this a serious upside of code that has a history of breaking. > > But one at the time, first I will finish testing and benchmarking the > pc->page removal. > Sure. > > > E.g. I have a suspicion that we might be able to do dirty accounting > > > without all the flags (we have them in the page anyway!) but use > > > proportionals instead. It's not page-accurate, but I think the > > > fundamental problem is solved: when the dirty ratio is exceeded, > > > throttle the cgroup with the biggest dirty share. > > > > Using proportionals is a choice. But, IIUC, users of memcg wants > > something like /proc/meminfo. It doesn't match. > > If I'm an user of container, I want an information like /proc/meminfo for > > container. > > I totally agree that this is information that needs exporting. > > But you can easily calculate an absolute number of bytes by applying a > memcg's relative proportion to the absolute amount of dirty pages for > example. The only difference is that it probably won't be 100% > accurate, but a few pages difference should really not matter for > user-visible statistics. > > No? > With proportionals, we can't handle account moving between cgroups. That means rmdir, force_empty, task_move can break dirty statistics into mess. Thanks, -Kame -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>