From: Thierry <reserv0@yahoo.com>
To: Thierry <reserv0@yahoo.com>, Michal Hocko <mhocko@kernel.org>
Cc: Alkis Georgopoulos <alkisg@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, bugzilla-daemon@bugzilla.kernel.org,
Mel Gorman <mgorman@techsingularity.net>,
Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [Bug 196157] New: 100+ times slower disk writes on 4.x+/i386/16+RAM, compared to 3.x
Date: Fri, 17 Aug 2018 11:29:45 +0000 (UTC) [thread overview]
Message-ID: <1978465524.8206495.1534505385491@mail.yahoo.com> (raw)
In-Reply-To: 1978465524.8206495.1534505385491.ref@mail.yahoo.com
On Fri, 8/17/18, Michal Hocko <mhocko@kernel.org> wrote:
> Have you tried to set highmem_is_dirtyable as suggested elsewhere?
I tried everything, and yes, that too, to no avail. The only solution is to limit the
available RAM to less than 12Gb, which is just unacceptable for me.
> I would like to stress out that 16GB with 32b kernels doesn't play really nice.
I would like to stress out that 32 Gb of RAM played totally nice and very smoothly
with v4.1 and older kernels... This got broken in v4.2 and never repaired since.
This is a very nasty regression, and my suggestion to keep v4.1 maintained till
that regression would finally get worked around fell into deaf ears...
> Even small changes (larger kernel memory footprint) can lead to all sorts of
> problems. I would really recommend using 64b kernels instead. There shouldn't be
> any real reason to stick with 32bhighmem based kernel for such a large beast.
> I strongly doubt the cpu itself would be 32b only.
The reasons are many (one of them dealing with being able to run old 32 bits
Linux distros but without the bugs and security flaws of old, unmaintained kernels).
But the reasons are not the problem here. The problem is that v4.2 introduced a
bug (*) that was never fixed since.
A shame, really. :-(
(*) and that bug also affected 64 bits kernels, at first, mind you, till v4.8.4 got
released; see my comment in my initial report here:
https://bugzilla.kernel.org/show_bug.cgi?id=110031#c14
next parent reply other threads:[~2018-08-17 11:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1978465524.8206495.1534505385491.ref@mail.yahoo.com>
2018-08-17 11:29 ` Thierry [this message]
2018-08-17 14:46 ` [Bug 196157] New: 100+ times slower disk writes on 4.x+/i386/16+RAM, compared to 3.x Michal Hocko
[not found] <328204943.8183321.1534496501208.ref@mail.yahoo.com>
2018-08-17 9:01 ` Thierry
2018-08-17 9:29 ` Michal Hocko
[not found] <234273956.1792577.1524210929280.ref@mail.yahoo.com>
2018-04-20 7:55 ` Thierry
[not found] <bug-196157-27@https.bugzilla.kernel.org/>
2017-06-22 19:37 ` Andrew Morton
2017-06-22 20:58 ` Alkis Georgopoulos
2017-06-23 7:13 ` Michal Hocko
2017-06-23 7:44 ` Alkis Georgopoulos
2017-06-23 11:38 ` Michal Hocko
2017-06-26 5:28 ` Alkis Georgopoulos
2017-06-26 5:46 ` Michal Hocko
2017-06-26 7:02 ` Alkis Georgopoulos
2017-06-26 9:12 ` Michal Hocko
2017-06-29 6:14 ` Alkis Georgopoulos
2017-06-29 7:16 ` Michal Hocko
2017-06-29 8:02 ` Alkis Georgopoulos
2018-04-19 20:36 ` Andrew Morton
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=1978465524.8206495.1534505385491@mail.yahoo.com \
--to=reserv0@yahoo.com \
--cc=akpm@linux-foundation.org \
--cc=alkisg@gmail.com \
--cc=bugzilla-daemon@bugzilla.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).