Balbir Singh wrote: [snip]
>> With the current dual list approach, something like that could be done >> by treating the container lists as pure FIFO (and ignore the reference >> bit and all that) and make container reclaim only unmap, not write out >> pages. >> >> Then global reclaim will do the work (if needed), and containers get >> churn, equating the page ownership. >> > > I did implement the unmap only logic for shared pages in version 2 > of my RSS controller > > http://lkml.org/lkml/2007/2/19/10 > > It can be added back if required quite easily. Pavel what do you think > about it? I think it's wrong. Look, when the container hits the limit and just unmaps the pages the following situation may occur: some *other* container will hit the global shortage and will have to wait till the other's pages are flushed to disk. This is not a true isolation. If we send the pages to the disk right when the container hits the limit we spend its time, its IO bandwidth, etc and allow for others to have the free set of pages without additional efforts. [snip] >>>> Because, if the data is shared between containers isolation is broken >>>> anyway >>>> and we might as well charge them equally [1]. >>>> >>>> Move the full reclaim structures from struct zone to these structures. >>>> >>>> >>>> struct reclaim; >>>> >>>> struct reclaim_zone { >>>> spinlock_t lru_lock; >>>> >>>> struct list_head active; >>>> struct list_head inactive; >>>> >>>> unsigned long nr_active; >>>> unsigned long nr_inactive; >>>> >>>> struct reclaim *reclaim; >>>> }; >>>> >>>> struct reclaim { >>>> struct reclaim_zone zone_reclaim[MAX_NR_ZONES]; >>>> >>>> spinlock_t containers_lock; >>>> struct list_head containers; >>>> unsigned long nr_containers; >>>> }; >>>> >>>> >>>> struct address_space { >>>> ... >>>> struct reclaim reclaim; >>>> }; >>>> Peter, could you prepare some POC patches instead? See, when looking at the patches is simpler to understand what is going on then when reading the plain text. Moreover, when making the patches some unexpected details of the kernel internals arise and the ideas begin to change... [snip] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
