вт, 13 нояб. 2018 г. в 21:43, Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>: > > > > Is it really necessary to have an extra thread in ksm just to add vma's > > > for scanning? Can we do it right from the scanner thread? Also, may be > > > it is better to add vma's at their creation time when KSM_MODE_ALWAYS is > > > enabled? > > > > > > Thank you, > > > Pasha > > > > Oh, thats a long story, and my english to bad for describe all things, > > even that hard to find linux-mm conversation several years ago about that. > > > > Anyway, so: > > In V2 - i use scanner thread to add VMA, but i think scanner do that > > with too high rate. > > i.e. walk on task list, and get new task every 20ms, to wait write semaphore, > > to get VMA... > > To high rate for task list scanner, i think it's overkill. > > > > About add VMA from creation time, > > UKSM add ksm_enter() hooks to mm subsystem, i port that to KSM. > > But some mm people say what they not like add KSM hooks to other subsystems. > > And want ksm do that internally by some way. > > > > Frankly speaking i didn't have enough knowledge and skills to do that > > another way in past time. > > They also suggest me look to THP for that logic, but i can't find how > > THP do that without hooks, and > > where THP truly scan memory. > > > > So, after all of that i implemented this in that way. > > In first iteration as part of ksm scan thread, and in second, by > > separate thread. > > Because that allow to add VMA in fully independent way. > > It still feels as a wrong direction. A new thread that adds random > VMA's to scan, and no way to optimize the queue fairness for example. > It should really be done at creation time, when VMA is created it > should be added to KSM scanning queue, or KSM main scanner thread > should go through VMA list in a coherent order. How you see queue fairness in that case? i.e. if you talk about moving from old VMA to new VMA, IIRC i can't find any whole kernel list of VMAs. i.e. i really understood what you don't like exactly, but for that we need add hooks as i already mentioned above. (And i already try get that to kernel [1]). So, as i wrote you below, i need some maintainer opinion in which way that responsible person of mm see 'right' implementation. > The design of having a separate thread is bad. I plan in the future to > add thread per node support to KSM, and this one odd thread won't > break things, to which queue should this thread add VMA if there are > multiple queues? That will be interesting to look :) But IMHO: I think you will need to add some code to ksm_enter(). Because madvise() internally call ksm_enter(). So ksm_enter() will decide which tread must process that. That not depends on caller. Thanks. > Thank you, > Pasha > - - - 1. https://lkml.org/lkml/2014/11/8/206
