On 02/10/2014 01:44 PM, Naoya Horiguchi wrote: > When we try to use multiple callbacks in different levels, skip control is > also important. For example we have thp enabled in normal configuration, and > we are interested in doing some work for a thp. But sometimes we want to > split it and handle as normal pages, and in another time user would handle > both at pmd level and pte level. > What we need is that when we've done pmd_entry() we want to decide whether > to go down to pte level handling based on the pmd_entry()'s result. So this > patch introduces a skip control flag in mm_walk. > We can't use the returned value for this purpose, because we already > defined the meaning of whole range of returned values (>0 is to terminate > page table walk in caller's specific manner, =0 is to continue to walk, > and <0 is to abort the walk in the general manner.) This seems a bit complicated for a case which doesn't exist in practice in the kernel today. We don't even *have* a single ->pte_entry handler. Everybody just sets ->pmd_entry and does the splitting and handling of individual pte entries in there. The only reason it's needed is because of the later patches in the series, which is kinda goofy. I'm biased, but I think the abstraction here is done in the wrong place. Naoya, could you take a looked at the new handler I proposed? Would that help make this simpler? -- 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>