[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |