[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/5] un-alias cpumask_any() from cpumask_first()



On Fri, Aug 23, 2013 at 8:52 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> In order to achieve more symmetric distribution of certain things,
> cpumask_any() shouldn't always pick the first CPU (which frequently
> will end up being CPU0). To facilitate that, introduce a library-like
> function to obtain random numbers.
>
> The per-architecture function is supposed to return zero if no valid
> random number can be obtained (implying that if occasionally zero got
> produced as random number, it wouldn't be considered such).
>
> As fallback this uses the trivial algorithm from the C standard,
> extended to produce "unsigned int" results.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -17,6 +17,7 @@ obj-y += multicall.o
>  obj-y += notifier.o
>  obj-y += page_alloc.o
>  obj-y += preempt.o
> +obj-y += random.o
>  obj-y += rangeset.o
>  obj-y += sched_credit.o
>  obj-y += sched_credit2.o
> --- /dev/null
> +++ b/xen/common/random.c
> @@ -0,0 +1,29 @@
> +#include <xen/percpu.h>
> +#include <xen/random.h>
> +#include <xen/time.h>
> +#include <asm/random.h>
> +
> +static DEFINE_PER_CPU(unsigned int, seed);
> +
> +unsigned int get_random(void)
> +{
> +    unsigned int next = this_cpu(seed), val = arch_get_random();

arch_get_random() isn't a random "fill in the value" call (like
this_cpu(seed) is, it's actually part of the algoritm.  I think it's
easier to read if it's separated from the variable declarations.

But that's a minor issue I'll leave to you.  Other than that:

Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.