static int's for proc_change_penalty and tlb_flush_penalty

[Mary Carroll Moore]

Take me off this email.  Thank you

> -----Original Message-----
> From: owner-linux-kernel en vger.rutgers.edu
> [mailto:owner-linux-kernel en vger.rutgers.edu]On Behalf Of Mike Karmyshev
> Sent: Thursday, January 20, 2000 3:21 AM
> To: linux-kernel en vger.rutgers.edu
> Subject: Re: static int's for proc_change_penalty and tlb_flush_penalty
>
>
>   James Manning wrote:
>   >
>   > I was thinking about making the penalties in goodness() for
> processor
>   > change and TLB flushes into static int's and putting them into /proc
>   > for ppl to be able to "tune" their SMP scheduler (and to find out
>  with
>   > some user feedback if there are more appropriate defaults for them,
>   > or whether it should really be settable per-system) but realized
> that
>   > even as a pair of static int's, the misses of that cache line may be
>   > adverse enough to ruin any chance of this being a worth-while
> change,
>   > so I wanted to get your opinion on this.
>   >
>   > Since these are just scheduling policy changes, atomicity WRT the
>  int's
>   > shouldn't matter (although the /proc change function should keep
> some
>   > reasonable bounds)
>   >
>   > Thoughts?
>   >
>   > James
>   Oops,I've already done it for testing purposes three or maybe four
>   months ago,when I had an Abit BP6 motherboard at home. Moved CPU
> change
>  penalty from constant   to sysctl to be able  to change it on the
> fly.It seems to me that
>  changing PENALTY value  doesn't  affect SMP performance too much.The
> difference was less than
>  2% on   PVMPovray benchmark.
> Somebody still wondering about it?
> --
> 	WBR,Mike
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo en vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/