On Tue 18-12-18 15:46:45, prakash.sangappa wrote: [...] > Dave Hansen asked how would it scale, with respect reading this file from > a large process. Answer is, the file contents are generated using page > table walk, and copied to user buffer. The mmap_sem lock is drop and > re-acquired in the process of walking the page table and copying file > content. The kernel buffer size used determines how long the lock is held. > Which can be further improved to drop the lock and re-acquire after a > fixed number(512) of pages are walked. I guess you are still missing the point here. Have you tried a larger mapping with interleaved memory policy? I would bet my hat that you are going to spend a large part of the time just pushing the output to the userspace... Not to mention the parsing on the consumer side. Also you keep failing (IMO) explaining _who_ is going to be the consumer of the file. What kind of analysis will need such an optimized data collection and what can you do about that? This is really _essential_ when adding a new interface to provide a data that is already available by other means. In other words tell us your specific usecase that is hitting a bottleneck that cannot be handled by the existing API and we can start considering a new one. -- Michal Hocko SUSE Labs
