Re: move-accounting-function-calls-out-of-critical-vm-code-paths.patch

[Christoph Lameter]

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/