From: Andrey Savochkin <saw@saw.sw.com.sg>
To: Jan Astalos <astalos@tuke.sk>
Cc: Yuri Pudgorodsky <yur@asplinux.ru>,
Linux MM mailing list <linux-mm@kvack.org>
Subject: Re: Question: memory management and QoS
Date: Mon, 28 Aug 2000 21:10:26 +0800 [thread overview]
Message-ID: <20000828211026.D6043@saw.sw.com.sg> (raw)
In-Reply-To: <39AA56D1.EC5635D3@tuke.sk>; from "Jan Astalos" on Mon, Aug 28, 2000 at 02:10:57PM
On Mon, Aug 28, 2000 at 02:10:57PM +0200, Jan Astalos wrote:
> Andrey Savochkin wrote:
[snip]
> >
> > That's what user beancounter patch is about.
> > Except that I'm not so strong in the judgements.
> > For example, I don't think that overcommits are evil. They are quite ok if
>
> Did you ever asked your users ? Whether they like to see their apps (possibly running
> for quite a long time) to be killed (no matter whether with or without warning) ?
Well, I was the person responsible for the work of servers (HTTP, FTP, mail,
proxy, statistic and accounting etc).
Yes, I want some applications to be killed under certain conditions.
>
> > 1. the system can provide guarantee that certain processes can never be
> > killed because of OOM;
>
> Again. I wonder how beancounter would prevent overcommit of virtual memory if you don't
> set limits...
It doesn't prevent overcommit.
And it doesn't prevent out-of-memory situations.
It prevents processes that stays below preconfigured threshold to face
negative consequences of overcommits, OOM or whatever else.
If OOM happens then _someone_ is over the threshold, and this very one will
face the consequences.
You propose exactly the same: user whose swap file ends is the only one who
faces problems. The difference is that with my code he likely avoids
problems if some other user doesn't consumed all his resources.
What you propose is just punish the user unconditionally, even if there are
some spare resources...
>
> > 2. the whole system reaction to OOM situation is well predictable.
> > It's a part of quality of service: some processes/groups of processes have
> > better service, some others only best effort.
>
> I wont repeat it again. With personal swapfiles _all_ users would be guarantied
> to get the amount of virtual memory provided by _themselves_.
Yes, personal swapfiles solve this problem, too.
They are just a waste of resources, to be very frank.
[snip]
> As a user, I won't bear _any_ overcommits at all. Once service is paid, I expect
> guarantied level of quality. In the case of VM, all the memory I paid for.
> For all of my processes.
It means that you pay orders of magnitude more for it.
> Do you mean "pages shared between processes of particular user" ? Where's the problem ?
> If you mean "pages provided by user to another user", I still don't see the problem...
>
> If you mean anonymous pages not owned by any user, I'm really interested why this should
> be allowed (to let some trash to pollute system resources. Is it common practice ?).
Well, you're speaking about private pages only.
I speak about all memory resources, in-core and swap, and all kinds of
memory, shared and private, file mapped and anonymous.
Regards
Andrey V.
Savochkin
--
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 prev parent reply other threads:[~2000-08-28 13:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2000-08-30 9:01 ` Jan Astalos
2000-08-30 11:42 ` Marco Colombo
2000-08-28 17:40 ` Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2000-08-24 10:13 Jan Astalos
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
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=20000828211026.D6043@saw.sw.com.sg \
--to=saw@saw.sw.com.sg \
--cc=astalos@tuke.sk \
--cc=linux-mm@kvack.org \
--cc=yur@asplinux.ru \
/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