From: "Carlos R. Mafra" <crmafra2@gmail.com>
To: Helge Hafting <helge.hafting@aitel.hist.no>
Cc: Mike Galbraith <efault@gmx.de>, Jan Knutar <jk-lkml@sci.fi>,
linux-kernel@vger.kernel.org, Hans-Peter Jansen <hpj@urpla.net>,
Jiri Kosina <jkosina@suse.cz>,
David Newall <davidn@davidnewall.com>,
Theodore Tso <tytso@mit.edu>, "Fred ." <eldmannen@gmail.com>
Subject: Swap makes X unfair (was Re: Keys get stuck)
Date: Thu, 13 Mar 2008 12:13:54 -0300 [thread overview]
Message-ID: <20080313151354.GA5252@localhost.ift.unesp.br> (raw)
In-Reply-To: <47D937A2.9070305@aitel.hist.no>
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.
next prev parent reply other threads:[~2008-03-13 15:13 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-11 23:32 Keys get stuck Fred .
2008-03-12 0:04 ` Andrew Morton
2008-03-12 8:48 ` Sebastien Dugue
2008-03-12 10:32 ` Jiri Kosina
2008-03-12 10:44 ` David Newall
2008-03-12 14:47 ` Theodore Tso
2008-03-12 15:20 ` Stephen Hemminger
2008-03-12 16:47 ` David Newall
2008-03-12 16:49 ` Jiri Kosina
2008-03-12 21:22 ` Hans-Peter Jansen
2008-03-13 5:42 ` Mike Galbraith
2008-03-13 9:48 ` Jan Knutar
2008-03-13 11:28 ` Mike Galbraith
2008-03-13 11:31 ` Jiri Kosina
2008-03-13 12:02 ` Mike Galbraith
2008-03-13 12:02 ` Carlos R. Mafra
2008-03-13 12:06 ` Jiri Kosina
2008-03-13 12:19 ` Carlos R. Mafra
2008-03-13 12:21 ` Mike Galbraith
2008-03-13 14:18 ` Helge Hafting
2008-03-13 15:13 ` Carlos R. Mafra [this message]
2008-03-14 11:02 ` Swap makes X unfair (was Re: Keys get stuck) Helge Hafting
2008-03-15 22:11 ` Carlos R. Mafra
2008-03-16 15:27 ` Jan Knutar
2008-03-14 18:34 ` Keys get stuck Pavel Machek
2008-03-13 17:14 ` Pavel Machek
2008-03-13 17:56 ` Fred .
2008-03-13 18:03 ` Pavel Machek
2008-03-14 9:21 ` Jiri Kosina
2008-03-14 18:24 ` Pavel Machek
2008-03-14 21:34 ` Lennart Sorensen
2008-03-14 13:30 ` Lennart Sorensen
2008-03-14 19:35 ` Pavel Machek
2008-03-13 13:01 ` Mark Lord
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080313151354.GA5252@localhost.ift.unesp.br \
--to=crmafra2@gmail.com \
--cc=davidn@davidnewall.com \
--cc=efault@gmx.de \
--cc=eldmannen@gmail.com \
--cc=helge.hafting@aitel.hist.no \
--cc=hpj@urpla.net \
--cc=jk-lkml@sci.fi \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox