This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PowerPC: Program Priority Register support


On Thu, May 23, 2013 at 9:05 AM, Adhemerval Zanella
<azanella@linux.vnet.ibm.com> wrote:
> Hi, some time ago I proposed a patch to save/restore the PowerPC Program
> Priority Register along with platform specific functions to set its value.
> However I later found out due a kernel limitation observed in the testcase
> (the value was reset to default value in every interruption) I didn't try
> to push.
>
> However now with Linux kernel 3.9 the PPR save/restore is implemented correctly
> within the kernel. So I'm simplifying the patch to just add the platform inline
> function to adjust the PPR value. The instruction are just nops on architectures
> that does not support PPR (pre-ISA 2.05) and on older kernel it will adjust the
> PPR on current process, but its value will be set to reset on a interrupt.
>
> Any comments, tips, advices?
>
> ---
>
> 2013-05-23  Adhemerval Zanella  <azanella@linux.vnet.ibm.com>
>
>         * manual/platform.texi: Add PowerPC PPR function set documentation.
>         * sysdeps/powerpc/sys/platform/ppc.h: Add PowerPC PPR set function
>         implementation.
>
> --
>
> diff --git a/manual/platform.texi b/manual/platform.texi
> index e387ff4..9803ba8 100644
> --- a/manual/platform.texi
> +++ b/manual/platform.texi
> @@ -34,3 +34,24 @@ This frequency is not related to the processor clock or the bus clock.
>  It is also possible that this frequency is not constant.  More information is
>  available in @cite{Power ISA 2.06b - Book II - Section 5.2}.
>  @end deftypefun
> +
> +@deftypefun {void} __ppc_set_ppr_med (void)
> +Set the Program Priority Register to medium value (default).
> +
> +The @dfn{Program Priority Register} (PPR) is a 64-bit register that controls
> +the program's priority. By adjusting the PPR value the programmer may
> +improve system throughput by causing the system resources to be used
> +more efficiently, especially in contention situations.
> +The three unprivileged states available are covered by the functions
> +__ppc_set_ppr_med (medium - default), __ppc_set_ppc_low (low) and
> +__ppc_set_ppc_med_low (medium low).  More information
> +available in @cite{Power ISA 2.06b - Book II - Section 3.1}.
> +@end deftypefun
> +
> +@deftypefun {void} __ppc_set_ppr_low (void)
> +Set the Program Priority Register to low value.
> +@end deftypefun
> +
> +@deftypefun {void} __ppc_set_ppr_med_low (void)
> +Set the Program Priority Register to medium low value.
> +@end deftypefun
> diff --git a/sysdeps/powerpc/sys/platform/ppc.h b/sysdeps/powerpc/sys/platform/ppc.h
> index 740831e..7cc0f1c 100644
> --- a/sysdeps/powerpc/sys/platform/ppc.h
> +++ b/sysdeps/powerpc/sys/platform/ppc.h
> @@ -50,4 +50,34 @@ __ppc_get_timebase (void)
>  #endif
>  }
>
> +
> +/* ISA 2.05 and beyond support the Program Priority Register (PPR) to adjust
> +   thread priorities based on lock acquisition, wait and release. The ISA
> +   defines the use of form 'or Rx,Rx,Rx' as the way to modify the PRI field.
> +   The unprivileged priorities are:
> +     Rx = 1 (low)
> +     Rx = 2 (medium)
> +     Rx = 6 (medium-low/normal)
> +   The 'or' instruction form is a nop in previous hardware, so it is safe to
> +   use unguarded. The default value is 'medium'.
> + */

You mention that Linux 3.9 supports PPR save/restore.  Did it also
redefine 'normal' to Rx=2 as we'd hoped/asked?

> +
> +static inline void
> +__ppc_set_ppr_med (void)
> +{
> +  __asm__ volatile ("or 2,2,2");
> +}
> +
> +static inline void
> +__ppc_set_ppr_med_low (void)
> +{
> +  __asm__ volatile ("or 6,6,6");
> +}
> +
> +static inline void
> +__ppc_set_ppr_low (void)
> +{
> +  __asm__ volatile ("or 1,1,1");
> +}
> +
>  #endif  /* sys/platform/ppc.h */

I suppose it doesn't make sense to have a test-case because an pre 3.9
kernel might task switch after a set.

Is there any sense/use in having a 'get' API?

Ryan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]