On Thu 28-07-16 07:33:19, NeilBrown wrote: > On Thu, Jul 28 2016, Michal Hocko wrote: > > > On Wed 27-07-16 13:43:35, NeilBrown wrote: > >> On Mon, Jul 25 2016, Michal Hocko wrote: > >> > >> > On Sat 23-07-16 10:12:24, NeilBrown wrote: > > [...] > >> So should there be a limit on dirty > >> pages in the swap cache just like there is for dirty pages in any > >> filesystem (the max_dirty_ratio thing) ?? > >> Maybe there is? > > > > There is no limit AFAIK. We are relying that the reclaim is throttled > > when necessary. > > Is that a bit indirect? Yes it is. Dunno, how much of a problem is that, though. > It is hard to tell without a clear big-picture. > Something to keep in mind anyway. > > > > >> I think we'd end up with cleaner code if we removed the cute-hacks. And > >> we'd be able to use 6 more GFP flags!! (though I do wonder if we really > >> need all those 26). > > > > Well, maybe we are able to remove those hacks, I wouldn't definitely > > be opposed. But right now I am not even convinced that the mempool > > specific gfp flags is the right way to go. > > I'm not suggesting a mempool-specific gfp flag. I'm suggesting a > transient-allocation gfp flag, which would be quite useful for mempool. > > Can you give more details on why using a gfp flag isn't your first choice > for guiding what happens when the system is trying to get a free page > :-? If we get rid of throttle_vm_writeout then I guess it might turn out to be unnecessary. There are other places which will still throttle but I believe those should be kept regardless of who is doing the allocation because they are helping the LRU scanning sane. I might be wrong here and bailing out from the reclaim rather than waiting would turn out better for some users but I would like to see whether the first approach works reasonably well. -- Michal Hocko SUSE Labs -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
