From: Jan Astalos <astalos@tuke.sk>
To: linux-mm@kvack.org
Subject: Question: memory management and QoS
Date: Thu, 24 Aug 2000 12:13:28 +0200 [thread overview]
Message-ID: <39A4F548.B8EB5308@tuke.sk> (raw)
Hello,
I have a question about possibility to provide Quality of Service
guaranties by Linux memory management. I'm asking this in the
context of possible use of Linux clusters in computational grids
(http://www.gridforum.org/). There is still more computing power
(mostly unused) in workstations...
One of the most important issues (IMO) is QoS. Especially, how
OS can guarantee availability of resources. Since Linux is
top-ranking OS in high-performance clusters, obviously there will
be need to implement QoS in it.
So, why am I writing this to this list ? In last couple of days
I was experimenting with Linux MM subsystem to find out whether
Linux can (how it could) assure exclusive access to some amount
of memory for user. Of course I was searching the archives. So
far, I found only the beancounter patch, which is designed for
limiting of memory usage. This is not quite exactly what I am
looking for. Rather, users should have their memory reserved...
If I missed something please send me the pointers.
I have some (rough) ideas how it could work and I would be
happy if you'll send me your opinions.
Concept of personal swapfiles:
- each user would have its own swapfile (size would depend on
his memory needs and disk quota, he would be able to resize it)
- system swapfile would be shared between daemons and superuser
- each active user would have some amount of physical pages
allocated (according to selected policy)
The benefits (among others):
- there wouldn't be system OOM (only per user OOM)
- user would be able to check his available memory
- no limits for VM address space
- there could be more policies for sharing of physical memory
by users (and system)
Drawbacks:
<please fill>
Thanks in advance for your comments,
Jan
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next reply other threads:[~2000-08-24 10:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-08-24 10:13 Jan Astalos [this message]
2000-08-28 7:47 ` Andrey Savochkin
2000-08-28 9:28 ` Jan Astalos
2000-08-28 11:30 ` Andrey Savochkin
2000-08-28 12:38 ` Jan Astalos
2000-08-28 17:25 ` Rik van Riel
2000-08-30 7:38 ` Jan Astalos
2000-08-30 16:53 ` Rik van Riel
2000-08-31 1:48 ` Andrey Savochkin
2000-08-31 11:49 ` Jan Astalos
2000-08-25 13:22 Yuri Pudgorodsky
2000-08-25 15:51 ` Jan Astalos
2000-08-25 20:17 ` Yuri Pudgorodsky
2000-08-28 8:36 ` Jan Astalos
2000-08-28 11:05 ` Andrey Savochkin
2000-08-28 12:10 ` Jan Astalos
2000-08-28 13:10 ` Andrey Savochkin
2000-08-30 9:01 ` Jan Astalos
2000-08-30 11:42 ` Marco Colombo
2000-08-28 17:40 ` Rik van Riel
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=39A4F548.B8EB5308@tuke.sk \
--to=astalos@tuke.sk \
--cc=linux-mm@kvack.org \
/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