Swap makes X unfair (was Re: Keys get stuck)

[Carlos R. Mafra]

On Thu 13.Mar'08 at 15:18:10 +0100, Helge Hafting wrote:
> Carlos R. Mafra wrote:
>> On Thu 13.Mar'08 at 12:28:13 +0100, Mike Galbraith wrote:
>>   
>>> [...]
>>> Swap can definitely keep X off the cpu for extended periods,
>>> [...]
>>>     
>>
>> So I would like to ask if swap letting X (and everything else
>> in my experience) out of the cpu for extended periods is
>> considered normal behaviour, in the sense that nobody is
>> trying to "fix" it (due to it being considered impossible
>> to fix)...?
>>   
> Yes, this is perfectly normal. A heavily swapping machine
> will swap out parts of X.

Right, but making the mistake of not being very precise
I would not say my desktop was "heavily swapping". 

> Now, if X has a need for low-latency for keyboard handling,
> then the X developers can use mlock to lock
> the X keyboard service in memory, and make it a real-time
> (or at least high priority) process too.  This should
> avoid the problem even with extreme swapping and/or
> high cpu load.

That would be a great thing for me. But why one wouldn't
want this behaviour to be default for a desktop? I mean
it should be like that already for a desktop experience.

I don't care if xjed takes longer to load the 380MB file 
while swapping something as long as I don't feel my 
desktop has come to an almost frozen state.

>> Sorry for being off-topic, but I run a minimal Window Maker
>> desktop in a P4 3.0 GHz with 512 MB of RAM (around 140 MB
>> being used as per 'free'), and trying to load a 380 MB text
>> file in xjed editor makes my whole desktop quite unfair...
>> it takes tens of seconds to switch desktop, type things in
>> the terminal etc. 
>>   
> Seems ou use too much memory then. 

Well, Window Maker by itself uses around 5-10 MB of RAM.
The 140 MB figure was with firefox and thunderbird openned,
plus a few xterm + mrxvt.

> If xjed
> wastes memory (by bringing the entire file into memory
> in one go) then you'll get some swapping.

I tried with emacs and it simply said something like this:
"Are you sure you want to open this big file?"
I said 'yes' and emacs reffused with "Buffer memory excedded" or
something like that.
At least xjed openned the file :-)

Well, I must say that 'vi' could open the file almost
immediately under the same situation tough.

>> Is there some law in the nature of computers which says
>> that when swapping everything else waits for swap to finish its business? 
>> I hope not :-)
>>   
> No such law, but there are badly implemented software
> around. If xjed is capable of delaying all X events while
> loading the file, for example . . .

Yeah, xjed uses too much memory for this, but it would be
"harmless" if there were some mechanism to prevent swap (not
too heavy) from starving the whole system.

Why can't there be a swap scheduler for this situation?
(I am sorry for being ignorant about it, there probably 
exists one).
If more than one process is using swap, they should use
it fairly. Put xjed's swap to rest for a moment, load the
swap due to X, and go forward.

My machine has 2 GB of swap area, both X and xjed swaps
could exist simultaneously without "having to wait to
long" for the other process business with swap to finish.

Please forgive me if I am being unfair about something,
I don't understand the internals of all this stuff.
That's why I first asked if having swap _not_ interfering
too much in other processes was impossible by some 
computer principle (like disks are not fast enough).

But it appears that it is something related to the
scheduling of what to read/write from/to swap and when.

Of course that's just what I think, and I would like
to learn more from knowleadgeble lkml people. Maybe
in trying to explain things to me, some hacker may
find that something could be made better, or point
me to some /sys tunnable which makes my experience
better.

--
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/