From: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: huang ying <huang.ying.caritas@gmail.com>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org
Subject: Re: kernel BUG at mm/swap_state.c:170!
Date: Thu, 25 Jul 2019 11:17:21 +0500 [thread overview]
Message-ID: <CABXGCsNRpq=AF1aRgyquszy2MZzVfKZwrKXiSW-PnGiAR652cg@mail.gmail.com> (raw)
In-Reply-To: <87zhl59w2t.fsf@yhuang-dev.intel.com>
On Tue, 23 Jul 2019 at 10:08, Huang, Ying <ying.huang@intel.com> wrote:
>
> Thanks! I have found another (easier way) to reproduce the panic.
> Could you try the below patch on top of v5.2-rc2? It can fix the panic
> for me.
>
Thanks! Amazing work! The patch fixes the issue completely. The system
worked at a high load of 16 hours without failures.
But still seems to me that page cache is being too actively crowded
out with a lack of memory. Since, in addition to the top speed SSD on
which the swap is located, there is also the slow HDD in the system
that just starts to rustle continuously when swap being used. It would
seem better to push some of the RAM onto a fast SSD into the swap
partition than to leave the slow HDD without a cache.
https://imgur.com/a/e8TIkBa
But I am afraid it will be difficult to implement such an algorithm
that analyzes the waiting time for the file I/O and waiting for paging
(memory) and decides to leave parts in memory where the waiting time
is more higher it would be more efficient for systems with several
drives with access speeds can vary greatly. By waiting time I mean
waiting time reading/writing to storage multiplied on the count of
hits. Thus, we will not just keep in memory the most popular parts of
the memory/disk, but also those parts of which read/write where was
most costly.
--
Best Regards,
Mike Gavrilov.
next prev parent reply other threads:[~2019-07-25 6:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-29 4:05 Mikhail Gavrilov
2019-05-29 17:32 ` Mikhail Gavrilov
2019-05-29 18:09 ` Michal Hocko
2019-05-29 19:28 ` Mikhail Gavrilov
2019-06-05 20:07 ` Mikhail Gavrilov
2019-06-11 3:59 ` Mikhail Gavrilov
2019-06-16 10:12 ` Mikhail Gavrilov
2019-06-17 12:17 ` Vlastimil Babka
2019-06-17 20:09 ` Mikhail Gavrilov
2019-06-30 21:15 ` Mikhail Gavrilov
2019-07-05 15:19 ` Mikhail Gavrilov
2019-07-05 23:03 ` Jan Kara
2019-07-06 2:39 ` Linus Torvalds
2019-06-17 12:47 ` Vlastimil Babka
2019-07-22 1:37 ` huang ying
2019-07-22 7:31 ` Mikhail Gavrilov
2019-07-22 7:52 ` Huang, Ying
2019-07-22 7:56 ` Mikhail Gavrilov
2019-07-23 5:08 ` Huang, Ying
2019-07-25 6:17 ` Mikhail Gavrilov [this message]
2019-07-25 7:14 ` Huang, Ying
2019-07-25 11:44 ` Matthew Wilcox
2019-07-26 3:20 ` Huang, Ying
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='CABXGCsNRpq=AF1aRgyquszy2MZzVfKZwrKXiSW-PnGiAR652cg@mail.gmail.com' \
--to=mikhail.v.gavrilov@gmail.com \
--cc=huang.ying.caritas@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ying.huang@intel.com \
/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