----- Original Message -----r. Hmm ;) Balbir and Pavel pointed out that the resouce which can shrink if necessary is - user's memory usage - kernel memory (slab) if it can. (not implemented) And there are other users of res_counter which cannot shrink. (I think -EBUSY should be returned) Now, my idea is - implement "feedback" in memcg because it is an only user - fix res_counter to return -EBUSY I think we can revisit later "implement generic feedback in res_counter". And such kind of implementation change will not big.(I think) Another point is I don't want to make res_counter big. To support generic ops in res_counter (handle limit, hierarchy, high-low watermark...) res_counter must be bigger that it is. And most of users of res_counder doesn' t want such ops. To be honest, both way is okay to me. But I'd like to start from not-invasive one. Thanks, -Kame --
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Amit K. Arora | [RFC] Heads up on sys_fallocate() |
| Linus Torvalds | Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes g... |
git: | |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Ray Lee | Re: [BUG] New Kernel Bugs |
