On Thu, 3 Feb 2005, Andrew Morton wrote:
> Has any performance testing been done?
Jay did some performance testing and found minor performance increases
without my page fault patches. But then the performance without the page
fault patches is already so bad due to the page_table_lock
contention that this is not so important.
> > acct_update_integrals is only useful to call if stime changes otherwise
> > it will simply return. It is therefore best to relocate the function call
> > to acct_update_integral into the function that updates stime which is
> > account_system_time and remove it from the vm code paths.
>
> But that changes (breaks) the semantics significantly. A task will now
> only have its BSD accounting fields updated when it happens to be
> interrupted by the timer. Some tasks:
>
> for ( ; ; ) {
> nanosleep(2 milliseconds);
> do_stuff_for(0.5 milliseconds);
> }
>
> will see their BSD accounting fields remaining stuck firmly at zero.
>
> I think?
Accounting is only effective is stime changes even with the current
code. If the process never gets its stime increased then also the
accounting does nothing. There is no change in that behavior.
> > update_mem_hiwater finds the rss hiwater mark. RSS limits are checked in
> > account_system_time().
>
> Linux doesn't check rss limits anywhere. We check CPU usage in
> account_system_time().
Yuck. I was mistaken in what check_rlimit does.
> Most of this could be fixed up by updating these counters at schedule()
> time as well, although that would become somewhat inaccurate if we later
> decide to implement rss enforcement at pagefault time.
Right. I hope that Roland's changes for higher resolution of cputime would
make that possible. But this is Jay's thing not mine. I just want to make
sure that the CSA patches does not get in the way of our attempts to
improve the performance of the page fault handler. In the discussions on
linux-mm there was also some concern about adding these calls.
Christoph Lameter <[email protected]> wrote:
>
> I hope that Roland's changes for higher resolution of cputime would
> make that possible. But this is Jay's thing not mine. I just want to make
> sure that the CSA patches does not get in the way of our attempts to
> improve the performance of the page fault handler. In the discussions on
> linux-mm there was also some concern about adding these calls.
Well your patch certainly cleans things up in there and would be a good
thing to have as long as we can be sure that it doesn't break the
accounting in some subtle way.
Which implies that we need to see some additional accounting code, so we
can verify that the base accumulation infrastructure is doing the expected
thing. As well as an ack from the interested parties. Does anyone know
what's happening with all the new accounting initiatives? I'm seeing no
activity at all.
On Thu, 3 Feb 2005, Andrew Morton wrote:
> Well your patch certainly cleans things up in there and would be a good
> thing to have as long as we can be sure that it doesn't break the
> accounting in some subtle way.
I think it also fits well with the other accounting data which is only
statistically probed at clock ticks.
> Which implies that we need to see some additional accounting code, so we
> can verify that the base accumulation infrastructure is doing the expected
> thing. As well as an ack from the interested parties. Does anyone know
> what's happening with all the new accounting initiatives? I'm seeing no
> activity at all.
Well, I'm here :), but I'm concentrating on making a GNU acct release
happen.
Anyways, as I'm not involved with memory accounting yet, I guess I should
leave it to CSA and ELSA people to comment.
Tim
On Thu, 3 Feb 2005, Andrew Morton wrote:
> Which implies that we need to see some additional accounting code, so we
> can verify that the base accumulation infrastructure is doing the expected
> thing. As well as an ack from the interested parties. Does anyone know
> what's happening with all the new accounting initiatives? I'm seeing no
> activity at all.
I'm following this discussion with a lot of interest. I'm working on a
user space tool for managing groups of processes in order to do
per-group accounting (ELSA). A release should be done quickly. To get
accounting values I'm using BSD per-process accounting and also the CSA
patch. Thus, I'm not directly working on accounting values and the
infrastructure provided by Christoph and CSA patch fit well with my
needs.
Best regards,
Guillaume
Andrew Morton wrote:
> Christoph Lameter <[email protected]> wrote:
>
>>I hope that Roland's changes for higher resolution of cputime would
>>make that possible. But this is Jay's thing not mine. I just want to make
>>sure that the CSA patches does not get in the way of our attempts to
>>improve the performance of the page fault handler. In the discussions on
>>linux-mm there was also some concern about adding these calls.
>
>
> Well your patch certainly cleans things up in there and would be a good
> thing to have as long as we can be sure that it doesn't break the
> accounting in some subtle way.
>
> Which implies that we need to see some additional accounting code, so we
> can verify that the base accumulation infrastructure is doing the expected
> thing. As well as an ack from the interested parties. Does anyone know
> what's happening with all the new accounting initiatives? I'm seeing no
> activity at all.
Sorry guys! I have been away for three weeks on short term disability.:(
I have tested Christoph's patch before the leave. It did work for CSA
and showed performance improvement on certain configuration.
CSA is currently implemented as a loadable module. I think ELSA is the
same, right? The use of the enhanced accounting data collection
code is not in the kernel tree. That was why Andrew did not see usage of
the accounting patches. Should i propose to include the CSA module in
the kernel then, Andrew? :)
Cheers,
- jay
Jay Lan <[email protected]> wrote:
>
> I have tested Christoph's patch before the leave. It did work for CSA
> and showed performance improvement on certain configuration.
OK, thanks.
> Should i propose to include the CSA module in
> the kernel then, Andrew? :)
Sure, if such an action is suitable for all the other parties who are
interested in enhanced system accounting.
What this ballgame needs is for someone to grab the bull by the horns and
run with it. This thing obviously requires a lot more cliches!
Selon Jay Lan <[email protected]>:
> CSA is currently implemented as a loadable module. I think ELSA is the
> same, right? The use of the enhanced accounting data collection
> code is not in the kernel tree. That was why Andrew did not see usage of
> the accounting patches. Should i propose to include the CSA module in
> the kernel then, Andrew? :)
In fact there is a module in ELSA but it's just to keep a trace of the processes
hierarchy in order to do processes group management and process group
accounting in user space.
The process group management is done by a user space daemon and the process
group accounting is done by a user space application that computes information
provided by BSD-per process accounting and/or CSA accounting with information
provided by the user space daemon.
Thus currently there is a module that relays information about forks but I'm
working on a kobject_uevent solution to send the fork event (thanks to Andrew
for the suggestion).
Thus, I will be interesting to see CSA module in the kernel.
Regards,
Guillaume