All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: Andrew Morton <akpm@digeo.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: must-fix list for 2.6.0
Date: Tue, 29 Apr 2003 21:52:59 -0700	[thread overview]
Message-ID: <20030430045259.GD8978@holomorphy.com> (raw)
In-Reply-To: <20030429214537.7c6a6aaf.akpm@digeo.com>

William Lee Irwin III <wli@holomorphy.com> wrote:
>> I didn't notice anything specific here about sys_remap_file_pages() vs.
>> truncate() (sans objrmap); did a fix fly by that I didn't notice,
>> or was it less of an issue than I thought it was?

On Tue, Apr 29, 2003 at 09:45:37PM -0700, Andrew Morton wrote:
> That's just a bug.  We can either go through and unmap all the pages via
> their rmap chains, or mark the vma as nonlinear and just anonymise the pages
> and to heck with the SIGBUS.  I'm not particularly fussed either way
> really...

Okay, I'll just fill in if no one else appears to do the busywork.


William Lee Irwin III <wli@holomorphy.com> wrote:
>> Also, the OOM killer fails to check lowmem; basically it just needs
>> -       if (nr_swap_pages > 0)
>> +       if (nr_swap_pages > 0 && nr_free_buffer_pages() > 0)
>> With that in addition to the OOM killer locking patch I posted and
>> another to completely eliminate mm-less processes from consideration
>> 64GB ia32 (with, of course, my oversized out-of-tree patch) recovers
>> from OOM instead of deadlocking after a mass-killing with swap online.

On Tue, Apr 29, 2003 at 09:45:37PM -0700, Andrew Morton wrote:
> Wanna send patch?

Absolutely; I'll arrange a more organized presentation around Thursday
(yes, I'm among the last-minute OLS people -- it couldn't be helped).


William Lee Irwin III <wli@holomorphy.com> wrote:
>> I'd be interested in more detailed descriptions of the user-level no
>> overcommit, dcacheicache, and truncated ext3 page issues after Thursday.

On Tue, Apr 29, 2003 at 09:45:37PM -0700, Andrew Morton wrote:
> The arithmetic in vm_enough_memory() is woefully inaccurate.  If you have no
> swap and then build up a lot of icache/dcache, vm_enough_memory()
> underestimates the amount of reclaimable memory by a lot and big mallocs
> fail.  If the i/dcache has internal fragmentation it gets even worse.
> I had a brief poke at that a while ago and decided it was basically hopeless.
> I suspect that assuming "all slab pages are reclaimable" would be the best
> fix here.

It sounds like some thought may be necessary if the above approach is
to be improved upon.


On Tue, Apr 29, 2003 at 09:45:37PM -0700, Andrew Morton wrote:
> The ext3 truncate pages are those pages which are on the LRU and have
> buffers, but that's _all_ they have.  They are instantly reclaimable and are
> basically free memory.  Only nobody knows that yet, so vm_enough_memory()
> gets it wrong.  The fix would be to nail these pages more aggressively in
> journal_unmap_buffer(), or to account for them and include that accounting in
> vm_emough_memory().  I'd prefer to just free the dang pages in
> journal_unmap_buffer().

Noted.


William Lee Irwin III <wli@holomorphy.com> wrote:
>> The latter sounds easy to address. It actually sounds like a 2.4.x
>> compatibility fix.

On Tue, Apr 29, 2003 at 09:45:37PM -0700, Andrew Morton wrote:
> davem thinks we shouldn't need it, and I've seen no bug reports that indicate
> that we _do_ need it, but Andi says we do.
> Certainly something needs to be done in that area - a ppc64 box with 16G of
> memory (all ZONE_DMA) cruises along with just 1M of memory free.

Okay, I'll classify that as a back-burner issue.

Thanks.


-- wli

  reply	other threads:[~2003-04-30  4:40 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-29 22:57 must-fix list for 2.6.0 Andrew Morton
2003-04-29 23:22 ` John Bradford
2003-04-29 23:37   ` Andrew Morton
2003-04-30  3:19 ` William Lee Irwin III
2003-04-30  4:45   ` Andrew Morton
2003-04-30  4:52     ` William Lee Irwin III [this message]
2003-05-01  4:32     ` William Lee Irwin III
2003-04-30  8:30 ` Benjamin Herrenschmidt
2003-04-30 10:16 ` Maciej Soltysiak
2003-04-30 19:11   ` Andrew Morton
2003-04-30 23:11     ` Rick Lindsley
2003-04-30 23:21       ` Andrew Morton
2003-04-30 23:47         ` viro
2003-04-30 23:59           ` Andrew Morton
2003-05-01  6:27             ` Christoph Hellwig
2003-05-01  5:49               ` Shawn
2003-05-01 10:14                 ` Christoph Hellwig
2003-05-01  9:47                   ` Alan Cox
2003-05-01 15:44               ` Robert Love
2003-05-01  0:09           ` Robert Love
2003-05-01  0:51             ` Gerrit Huizenga
2003-05-01  5:40               ` Dave Hansen
2003-05-01 11:57                 ` Bill Huey
2003-04-30 23:53         ` Robert Love
2003-05-01  8:36         ` Arjan van de Ven
2003-05-01  8:42           ` Andrew Morton
2003-05-01  8:47             ` Arjan van de Ven
2003-04-30 23:41       ` Robert Love
2003-05-01 16:50         ` Hubertus Franke
2003-05-01  3:21     ` Mike Galbraith
2003-05-01  6:26       ` Mike Galbraith
2003-05-01 14:33 ` Christoph Hellwig
2003-05-01 18:42   ` Andrew Morton
2003-05-01 18:47     ` Christoph Hellwig
2003-05-02  1:57       ` Andreas Boman
     [not found] <20030429155731.07811707.akpm@digeo.com.suse.lists.linux.kernel>
2003-04-30  1:36 ` Andi Kleen
2003-04-30 18:09   ` Pavel Machek
2003-04-30 18:15     ` Andi Kleen
2003-04-30 19:11       ` Pavel Machek
     [not found] <20030429231009$1e6b@gated-at.bofh.it>
2003-04-30  4:55 ` Florian Weimer
2003-04-30 10:18   ` Maciej Soltysiak
2003-05-01 11:24   ` David S. Miller
2003-05-01 11:27     ` Florian Weimer
2003-05-01 12:03       ` David S. Miller
2003-05-01 12:05       ` David S. Miller
2003-05-02 16:28         ` Carl-Daniel Hailfinger
2003-05-02 21:14           ` David S. Miller

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=20030430045259.GD8978@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.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 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.