From: Stephan von Krawczynski <skraw@ithnet.com>
To: <mingo@elte.hu>
Cc: bcrl@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [patch] mempool-2.5.1-D2
Date: Sat, 15 Dec 2001 18:50:10 +0100 [thread overview]
Message-ID: <20011215185010.74837327.skraw@ithnet.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0112150653310.22818-100000@localhost.localdomain>
In-Reply-To: <20011214172728.B26535@redhat.com> <Pine.LNX.4.33.0112150653310.22818-100000@localhost.localdomain>
On Sat, 15 Dec 2001 07:41:12 +0100 (CET)
Ingo Molnar <mingo@elte.hu> wrote:
> - mempool_alloc(), if called from a process context, never fails. This
> simplifies lowlevel IO code (which often must not fail) visibly.
Uh, do you trust your own word? This already sounds like an upcoming deadlock
to me _now_. I saw a lot of try-and-error during the last month regarding
exactly this point. There have been VM-days where allocs didn't really fail
(set with right flags), but didn't come back either. And exactly this was the
reason why the stuff was _broken_. Obviously no process can wait a indefinitely
long time to get its alloc fulfilled. And there are conditions under heavy load
where this cannot be met, and you will see complete stall.
In fact I pretty much agree to Ben's thesis that the current allocator has a
problem. I would not call it broken, but it cannot present the ad-hoc answer to
one (_the_) important question: what is the correct cache page to drop _now_
when resources get low and I have to successfully return an allocation?
This is _the_ central issue that must be solved in a VM with such a tremendous
page caching going on like we have now. And really important is the fact the
answer must be presentable ad-hoc. If you have to loop around, wait for I/O or
whatever, then the basic design is already sub-optimal.
Looking at your mempool-ideas one cannot fight the impression that you try to
"patch" around a deficiency of the current code. This cannot be the right thing
to do.
Regards,
Stephan
next prev parent reply other threads:[~2001-12-15 17:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-14 13:49 [patch] mempool-2.5.1-D0 Ingo Molnar
2001-12-14 18:14 ` [patch] mempool-2.5.1-D1 Ingo Molnar
2001-12-14 19:13 ` [patch] mempool-2.5.1-D2 Ingo Molnar
2001-12-14 22:27 ` Benjamin LaHaise
2001-12-15 6:41 ` Ingo Molnar
2001-12-15 5:29 ` Benjamin LaHaise
2001-12-15 17:50 ` Stephan von Krawczynski [this message]
2001-12-18 0:46 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2001-12-15 22:17 Ingo Molnar
2001-12-17 16:19 ` Stephan von Krawczynski
2001-12-17 20:56 ` Ingo Molnar
2001-12-17 20:44 ` Benjamin LaHaise
2001-12-17 23:57 ` Stephan von Krawczynski
2001-12-18 16:43 ` Ingo Molnar
2001-12-18 15:36 ` Stephan von Krawczynski
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=20011215185010.74837327.skraw@ithnet.com \
--to=skraw@ithnet.com \
--cc=bcrl@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.