Hi Stefane,
Greetings from New Delhi. There are other kernel calls that take
vector arguments...writev for example. What is the behavior there if
one of the entries is botched? Does it provide any clue as to which
element was bad?
From the tool side, it's no problem in user code to 'try and try
again' in such a scenario, like PAPI.
If this results in an increased likelyhood of kernel adoption, then
I'm all for it. But when all is said and done, if we still get the
big NO, then I'd recommend keeping around all this stuff that got
pulled out.
Does the below require an interface change from the user and/or PFM
side? Please say no. PFM and Perfmon is now going into production in
various places (not just SiCortex or PAPI) and it would be nice to
start being sensitive to this issue. For every interface change that
comes out, that's #ifdefs, configure hacking and additional code that
must be maintained.
Anyways, I'd say go for it.
Regards,
Phil
On Sep 25, 2007, at 2:13 AM, Stephane Eranian wrote:
Hello,
I am still trying to remove unused code to simplify perfmon so that
others can
understand it better.
I have identified some code which is not really used and which does
not add
much value.
As you know many perfmon sysem calls take vector arguments, e.g.,
pfm_write_pmds().
If one element in the vector is buggy, the system call fails. The
interface
guarantees that all elements up to the faulty element are applied.
The current interface marks the faulty element such that it can be
identified.
For pfm_write_pmds(), the reg_flags field is updated and may report
EINVAL
or NOSET. The intent was to quickly identify the faulty element.
The downside of this is that the argument is modified and therefore
there needs
to be a copy_to_user() on exit. This also makes it more difficult
for tools when they
want to apply the same settings to multiple contexts in parallel,
e.g., in system-wide.
the vectors need to be copied.
I am proposing that we drop the modified system call args for all
vecotr arguments. The
only error message will be the return value of the syscall. It
would be possible to
idnetify the faulty entry by trying with a shorter vector or using
binaryt search if
necessary. In reality I think very few tools bother to understand
to that level of
details why a call fails.
The change will simplify the perfmon system calls and provide a
performance boost
because the copy_to_user() will be removed.
Any comments?
--
-Stephane
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
