> > Probably we have multiple option. but I don't think GFP_NOIO is good > > option. It assume the system have lots non-dirty cache memory and it isn't > > guranteed. > > Basically nothing is guaranteed in this case. However, does it actually make > things _worse_? Hmm.. Do you mean we don't need to prevent accidental suspend failure? Perhaps, I did misunderstand your intention. If you think your patch solve this this issue, I still disagree. but If you think your patch mitigate the pain of this issue, I agree it. I don't have any reason to oppose your first patch. > What _exactly_ does happen without the $subject patch if the > system doesn't have non-dirty cache memory and someone makes a GFP_KERNEL > allocation during suspend? Page allocator prefer to spent lots time for reclaimable memory searching than returning NULL. IOW, it can spent time few second if it doesn't have reclaimable memory. In typical case, OOM killer forcely make enough free memory if the system don't have any memory. But under suspending time, oom killer is disabled. So, if the caller (probably drivers) call alloc >1000times, the system spent lots seconds. In this case, GFP_NOIO doesn't help. slowness behavior is caused by freeable memory search, not slow i/o. However, if strange i/o device makes any i/o slowness, GFP_NOIO might help. In this case, please don't ask me about i/o thing. I don't know ;) _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
