On Tue, Jun 30, 2015 at 12:46:54PM +0200, Ingo Molnar wrote: > > * Mel Gorman <mgorman@xxxxxxx> wrote: > > > [...] > > > > Basically, overall I feel this series is the wrong approach but not knowing who > > the users are making is much harder to judge. I strongly suspect that if > > mirrored memory is to be properly used then it needs to be available before the > > page allocator is even active. Once active, there needs to be controlled access > > for allocation requests that are really critical to mirror and not just all > > kernel allocations. None of that would use a MIGRATE_TYPE approach. It would be > > alterations to the bootmem allocator and access to an explicit reserve that is > > not accounted for as "free memory" and accessed via an explicit GFP flag. > > So I think the main goal is to avoid kernel crashes when a #MC memory fault > arrives on a piece of memory that is owned by the kernel. > Sounds logical. In that case, bootmem awareness would be crucial. Enabling support in just the page allocator is too late. > In that sense 'protecting' all kernel allocations is natural: we don't know how to > recover from faults that affect kernel memory. > It potentially uses all mirrored memory on memory that does not need that sort of guarantee. For example, if there was a MC on memory backing the inode cache then potentially that is recoverable as long as the inodes were not dirty. That's a minor detail as the kernel could later protect only MIGRATE_UNMOVABLE requests instead of all kernel allocations if fatal MC in kernel space could be distinguished from non-fatal checks. Bootmem awareness is much more important either way. If that was addressed then potentially a MIGRATE_UNMOVABLE_MIRROR type could be created that is only used for MIGRATE_UNMOVABLE allocations and never for user-space. That misses MIGRATE_RECLAIMABLE so if that is required then we need something else that both preserves fragmentation avoidance and avoid introducing loads of new migratetypes. Reclaim-related issues could be partially avoided by forbidding use from userspace and accounting for the size of MIGRATE_UNMOVABLE_MIRROR during watermark checks. > We do know how to recover from faults that affect user-space memory alone. > > So if a mechanism is in place that prioritizes 3 groups of allocators: > > - non-recoverable memory (kernel allocations mostly) > So bootmem at the very least followed by MIGRATE_UNMOVABLE requests whether they are accounted for by zones of MIGRATE_TYPES. > - high priority user memory (critical apps that must never fail) > This one is problematic with a MIGRATE_TYPE-based approach such as the one in this series. If a high priority requires memory and MIGRATE_MIRROR is full then some of it must be reclaimed. With a MIGRATE_TYPE approach, the kernel may reclaim a lot of unnecessary memory trying to free some MIGRATE_MIRROR memory with no guarantee of success. It'll look like unnecessary thrashing from userspace but difficult to diagnose as reclaim stats are per-zone based. Dealing with this needs either a zone-based approach or a lot of surgery to reclaim (similar to what the node-based LRU series does actually when it skips pages when the caller requires lowmem pages). -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>