Cool thanks :)
> [..] But something happened with interactivity. If to start the
> countable task, enter on the computer on ssh, to make "su" - bothers to wait.
>
> On 2.4.19pre8aa3 such was not. Because of "O1"?
if it's a userspace-cpu intensive background load, most probably because
of o1. The dyn-sched (before I integraed o1 that obsoleted it) was very
good at detecting cpu hogs and to avoid them to disturb interactive
tasks like ssh-shell, of course o1 also has a sleep_time/sleep_avg
derived from the dyn-sched idea from Davide, but maybe the constants are
tuned in a different manner.
Can you try to renice at +19 the cpu hogs and see if you still get bad
interactivity?
The other possibility is that the bad interactivity is due to bad
sched-latency, so that the scheduler posts a reschedule via irq
(schedule_tick()) but the function schedule() is never invoked because
the kernel spins on a loop etc... Now the fixes to prune_icache might
have increased the sched-latency in some case when you shrink the cache
but in turn now you release the inodes and also we roll the list, so
overall should be even an improvement for sched latency for you. And I
doubt you're exercising such path so frequently that it makes a
difference (even if you're certainly exercising it to test the fix
worked). So I would suggest to run some readprofile and to see if
prune_icache/invalidate_inode_pages goes up a lot in the profiling. Also
please check if the cpu load is all in userspace during the bad
interactivity, if it's all userspace load the bad sched latency is
almost certainly not the case.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/