On Fri, Jun 22, 2018 at 11:51:38AM +0800, Huang, Ying wrote:
> +++ b/mm/swap_state.c
> @@ -426,33 +447,37 @@ struct page *__read_swap_cache_async(swp_entry_t entry, 
> gfp_t gfp_mask,
>               /*
>                * call radix_tree_preload() while we can wait.
>                */
> -             err = radix_tree_maybe_preload(gfp_mask & GFP_KERNEL);
> +             err = radix_tree_maybe_preload_order(gfp_mask & GFP_KERNEL,
> +                                                  compound_order(new_page));
>               if (err)
>                       break;

There's no more preloading in the XArray world, so this can just be dropped.

>               /*
>                * Swap entry may have been freed since our caller observed it.
>                */
> +             err = swapcache_prepare(hentry, huge_cluster);
> +             if (err) {
>                       radix_tree_preload_end();
> -                     break;
> +                     if (err == -EEXIST) {
> +                             /*
> +                              * We might race against get_swap_page() and
> +                              * stumble across a SWAP_HAS_CACHE swap_map
> +                              * entry whose page has not been brought into
> +                              * the swapcache yet.
> +                              */
> +                             cond_resched();
> +                             continue;
> +                     } else if (err == -ENOTDIR) {
> +                             /* huge swap cluster is split under us */
> +                             continue;
> +                     } else          /* swp entry is obsolete ? */
> +                             break;

I'm not entirely happy about -ENOTDIR being overloaded to mean this.
Maybe we can return a new enum rather than an errno?

Also, I'm not sure that a true/false parameter is the right approach for
"is this a huge page".  I think we'll have usecases for swap entries which
are both larger and smaller than PMD_SIZE.

I was hoping to encode the swap entry size into the entry; we only need one
extra bit to do that (no matter the size of the entry).  I detailed the
encoding scheme here:

https://plus.google.com/117536210417097546339/posts/hvctn17WUZu

(let me know if that doesn't work for you; I'm not very experienced with
this G+ thing)

Reply via email to