From: Mike Kravetz <mike.kravetz@oracle.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: James Houghton <jthoughton@google.com>,
Michal Hocko <mhocko@suse.com>,
David Rientjes <rientjes@google.com>,
linux-mm@kvack.org, David Hildenbrand <david@redhat.com>,
John Hubbard <jhubbard@nvidia.com>, Peter Xu <peterx@redhat.com>,
Vlastimil Babka <vbabka@suse.cz>, Zi Yan <ziy@nvidia.com>
Subject: Re: [Invitation] Linux MM Alignment Session on HugeTLB Core MM Convergence on Wednesday
Date: Thu, 15 Jun 2023 10:59:53 -0700 [thread overview]
Message-ID: <20230615175953.GA11169@monkey> (raw)
In-Reply-To: <ZItH6VWksesISUUJ@casper.infradead.org>
On 06/15/23 18:18, Matthew Wilcox wrote:
> On Thu, Jun 15, 2023 at 10:00:41AM -0700, James Houghton wrote:
> > I can't speak in detail about how databases recover from memory
> > poison. Mike, maybe you can share more details?
>
> Speaking generally (this would describe MySQL as well as any number of
> proprietary databases), hugetlbfs is used by databases as a supplier
> of memory to their userspace buffer cache. As database blocks are
> needed, they're read from storage using O_DIRECT. Depending on the
> database, they may or may not be updated in place.
>
> Just as in our page cache, if the hwpoison hits in a clean block, it
> can discard the block and re-read it. If it hits in a dirty block, it's
> Game Over. Most blocks are clean. A 1GB page contains so many blocks
> that taking out the entire 1GB is guaranteed to take out a dirty block.
> Taking out a single 4kB page is likely to take out only clean blocks.
Thanks Matthew.
I do not have details of exactly how this is done. However, this does fit
in with discussions I have had with our DB team. They can possibly recover
using another (older) copy of the data. The smaller the size of data, the
greater the possibility the older data can be used.
--
Mike Kravetz
next prev parent reply other threads:[~2023-06-15 18:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <c5afdf35-a5fa-03e2-348d-cf1d990fc389@google.com>
[not found] ` <20230614230458.GB3559@monkey>
2023-06-15 1:12 ` [Invitation] Linux MM Alignment Session on HugeTLB Core MM Convergence on Wednesday David Rientjes
2023-06-15 8:04 ` Michal Hocko
2023-06-15 8:29 ` David Hildenbrand
2023-06-15 17:24 ` James Houghton
2023-06-15 18:58 ` Peter Xu
2023-06-15 18:31 ` Mike Kravetz
2023-06-15 17:00 ` James Houghton
2023-06-15 17:18 ` Matthew Wilcox
2023-06-15 17:59 ` Mike Kravetz [this message]
2023-06-13 2:01 David Rientjes
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=20230615175953.GA11169@monkey \
--to=mike.kravetz@oracle.com \
--cc=david@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=jthoughton@google.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=peterx@redhat.com \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=ziy@nvidia.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;
as well as URLs for NNTP newsgroup(s).