lkml.org 
[lkml]   [2019]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v5 1/6] mm: Adjust shuffle code to allow for future coalescing
On Mon, Aug 12, 2019 at 2:33 PM Alexander Duyck
<alexander.duyck@gmail.com> wrote:
>
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>
> This patch is meant to move the head/tail adding logic out of the shuffle

s/This patch is meant to move/Move/

> code and into the __free_one_page function since ultimately that is where
> it is really needed anyway. By doing this we should be able to reduce the
> overhead

Is the overhead benefit observable? I would expect the overhead of
get_random_u64() dominates.

> and can consolidate all of the list addition bits in one spot.

This sounds the better argument.

[..]
> diff --git a/mm/shuffle.h b/mm/shuffle.h
> index 777a257a0d2f..add763cc0995 100644
> --- a/mm/shuffle.h
> +++ b/mm/shuffle.h
> @@ -3,6 +3,7 @@
> #ifndef _MM_SHUFFLE_H
> #define _MM_SHUFFLE_H
> #include <linux/jump_label.h>
> +#include <linux/random.h>
>
> /*
> * SHUFFLE_ENABLE is called from the command line enabling path, or by
> @@ -43,6 +44,32 @@ static inline bool is_shuffle_order(int order)
> return false;
> return order >= SHUFFLE_ORDER;
> }
> +
> +static inline bool shuffle_add_to_tail(void)
> +{
> + static u64 rand;
> + static u8 rand_bits;
> + u64 rand_old;
> +
> + /*
> + * The lack of locking is deliberate. If 2 threads race to
> + * update the rand state it just adds to the entropy.
> + */
> + if (rand_bits-- == 0) {
> + rand_bits = 64;
> + rand = get_random_u64();
> + }
> +
> + /*
> + * Test highest order bit while shifting our random value. This
> + * should result in us testing for the carry flag following the
> + * shift.
> + */
> + rand_old = rand;
> + rand <<= 1;
> +
> + return rand < rand_old;
> +}

This function seems too involved to be a static inline and I believe
each compilation unit that might call this routine gets it's own copy
of 'rand' and 'rand_bits' when the original expectation is that they
are global. How about leave this bit to mm/shuffle.c and rename it
coin_flip(), or something more generic, since it does not
'add_to_tail'? The 'add_to_tail' action is something the caller
decides.

\
 
 \ /
  Last update: 2019-08-13 00:25    [W:0.121 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site