step1: http://patchwork.ozlabs.org/patch/71489/
step2: http://patchwork.ozlabs.org/patch/81423/
In step2 I defined sysfs node as:
static SYSDEV_ATTR(dscr_default, 0600, show_dscr_default, store_dscr_default);
and it caused problems with rhel6.
Now it is:
static SYSDEV_CLASS_ATTR(dscr_default, 0600, show_dscr_default, store_dscr_default);
It works now on both 2.6.32 and 2.6.36 but is that correct?
--
Alexey Kardashevskiy
IBM OzLabs, LTC Team
e-mail/sametime: aik@au1.ibm.com
notes: Alexey Kardashevskiy/Australia/IBM
RHEL6 problem was that it crashed when doing
echo 3 > /sys/devices/system/cpu/dscr_default
because access methods for SYSDEV_ATTR and SYSDEV_CLASS_ATTR have different number of parameters in RHEL6. It was not correct for 2.6.36 either but the parameters number is the same for both SYSDEV_ATTR and SYSDEV_CLASS_ATTR and 2.6.36 simply forgave me.
--
Alexey Kardashevskiy
IBM OzLabs, LTC Team
e-mail/sametime: aik@au1.ibm.com
notes: Alexey Kardashevskiy/Australia/IBM
On Wed, 2011-02-16 at 16:38 +1100, Alexey Kardashevskiy wrote:
step1: http://patchwork.ozlabs.org/patch/71489/
step2: http://patchwork.ozlabs.org/patch/81423/
In step2 I defined sysfs node as:
static SYSDEV_ATTR(dscr_default, 0600, show_dscr_default,
store_dscr_default);
and it caused problems with rhel6.
Now it is:
static SYSDEV_CLASS_ATTR(dscr_default, 0600, show_dscr_default,
store_dscr_default);
It works now on both 2.6.32 and 2.6.36 but is that correct?
Ok, please resend with a proper changeset comment, something like that
would do:
<<
The DSCR (aka Data Stream Control Register) is supported on some
server PowerPC chips and allow some control over the prefetch
of data streams.
This patch allows the value to specified per thread by emulating
the corresponding mfspr and mtspr instructions. Children of such
threads inherit the value. Other threads use a default value that
can be specified in sysfs.
quoted
And include your Signed-off-by: line.
BTW. I suppose it's an expected behaviour that thread created with a
given default value will keep that value even when the default is later
changed right ? And their descendents will use the same default as the
original thread, not the new default, at least that's how I read your
code :-) Maybe that should be documented somewhere...
Cheers,
Ben.
On 02/03/11 16:47, Benjamin Herrenschmidt wrote:
BTW. I suppose it's an expected behaviour that thread created with a
given default value will keep that value even when the default is later
changed right ? And their descendents will use the same default as the
original thread, not the new default, at least that's how I read your
code :-) Maybe that should be documented somewhere...
That's right. The idea was to let one set of processes-which-do-not-access-dscr-directly to work+fork with one value and other set to work+fork with another value. I have no idea who and how is going to use it though. Hope the HPC team tells me if something is wrong :-)
--
Alexey Kardashevskiy
IBM OzLabs, LTC Team
e-mail/sametime: aik@au1.ibm.com
notes: Alexey Kardashevskiy/Australia/IBM