From: Mike Kravetz <mike.kravetz@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: mhocko@suse.com, jmarchan@redhat.com,
Dongwon Kim <dongwon.kim@intel.com>,
Junxiao Chang <junxiao.chang@intel.com>,
muchun.song@linux.dev, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
Vivek Kasireddy <vivek.kasireddy@intel.com>,
linux-mm@kvack.org, James Houghton <jthoughton@google.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
kirill.shutemov@linux.intel.com
Subject: Re: [PATCH] mm: fix hugetlb page unmap count balance issue
Date: Wed, 7 Jun 2023 14:16:55 -0700 [thread overview]
Message-ID: <20230607211655.GB4122@monkey> (raw)
In-Reply-To: <20230607140001.6685b0a058511f125a005da4@linux-foundation.org>
On 06/07/23 14:00, Andrew Morton wrote:
> On Wed, 7 Jun 2023 13:53:10 -0700 Mike Kravetz <mike.kravetz@oracle.com> wrote:
>
> > >
> > > BUGs aren't good. Can we please find a way to push this along?
> > >
> > > Have we heard anything from any udmabuf people?
> > >
> >
> > I have not heard anything. When this issue popped up, it took me by surprise.
> >
> > udmabuf maintainer (Gerd Hoffmann), the people who added hugetlb support and
> > the list where udmabuf was developed (dri-devel@lists.freedesktop.org) have
> > been on cc.
>
> Maybe Greg can suggest a way forward.
>
> > My 'gut reaction' would be to remove hugetlb support from udmabuf. From a
> > quick look, if we really want this support then there will need to be some
> > API changes. For example UDMABUF_CREATE should be hugetlb page aligned
> > and a multiple of hugetlb page size if using a hugetlb mapping.
> >
> > It would be good to know about users of the driver.
>
> So disabling "hugetlb=on" (and adding an explanatory printk) would
> suffice for now?
I can put together a patch to do that.
--
Mike Kravetz
WARNING: multiple messages have this Message-ID (diff)
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
Junxiao Chang <junxiao.chang@intel.com>,
kirill.shutemov@linux.intel.com, mhocko@suse.com,
jmarchan@redhat.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, muchun.song@linux.dev,
Vivek Kasireddy <vivek.kasireddy@intel.com>,
Dongwon Kim <dongwon.kim@intel.com>,
James Houghton <jthoughton@google.com>,
dri-devel@lists.freedesktop.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] mm: fix hugetlb page unmap count balance issue
Date: Wed, 7 Jun 2023 14:16:55 -0700 [thread overview]
Message-ID: <20230607211655.GB4122@monkey> (raw)
In-Reply-To: <20230607140001.6685b0a058511f125a005da4@linux-foundation.org>
On 06/07/23 14:00, Andrew Morton wrote:
> On Wed, 7 Jun 2023 13:53:10 -0700 Mike Kravetz <mike.kravetz@oracle.com> wrote:
>
> > >
> > > BUGs aren't good. Can we please find a way to push this along?
> > >
> > > Have we heard anything from any udmabuf people?
> > >
> >
> > I have not heard anything. When this issue popped up, it took me by surprise.
> >
> > udmabuf maintainer (Gerd Hoffmann), the people who added hugetlb support and
> > the list where udmabuf was developed (dri-devel@lists.freedesktop.org) have
> > been on cc.
>
> Maybe Greg can suggest a way forward.
>
> > My 'gut reaction' would be to remove hugetlb support from udmabuf. From a
> > quick look, if we really want this support then there will need to be some
> > API changes. For example UDMABUF_CREATE should be hugetlb page aligned
> > and a multiple of hugetlb page size if using a hugetlb mapping.
> >
> > It would be good to know about users of the driver.
>
> So disabling "hugetlb=on" (and adding an explanatory printk) would
> suffice for now?
I can put together a patch to do that.
--
Mike Kravetz
next prev parent reply other threads:[~2023-06-08 7:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-12 7:20 [PATCH] mm: fix hugetlb page unmap count balance issue Junxiao Chang
2023-05-12 21:03 ` Andrew Morton
2023-05-15 0:08 ` Chang, Junxiao
2023-05-12 21:26 ` James Houghton
2023-05-12 23:29 ` Mike Kravetz
2023-05-15 0:44 ` Chang, Junxiao
2023-05-15 17:04 ` Mike Kravetz
2023-05-15 17:04 ` Mike Kravetz
2023-05-16 22:34 ` Mike Kravetz
2023-05-16 22:34 ` Mike Kravetz
2023-06-07 19:03 ` Andrew Morton
2023-06-07 19:03 ` Andrew Morton
2023-06-07 20:53 ` Mike Kravetz
2023-06-07 20:53 ` Mike Kravetz
2023-06-07 21:00 ` Andrew Morton
2023-06-07 21:00 ` Andrew Morton
2023-06-07 21:16 ` Mike Kravetz [this message]
2023-06-07 21:16 ` Mike Kravetz
2023-06-08 7:59 ` Greg Kroah-Hartman
2023-06-08 7:59 ` Greg Kroah-Hartman
2023-06-07 19:27 ` David Hildenbrand
2023-06-07 19:27 ` David Hildenbrand
2023-06-19 12:27 ` Gerd Hoffmann
2023-06-19 12:27 ` Gerd Hoffmann
2023-06-20 6:23 ` Kasireddy, Vivek
2023-06-20 6:23 ` Kasireddy, Vivek
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=20230607211655.GB4122@monkey \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=dongwon.kim@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=jmarchan@redhat.com \
--cc=jthoughton@google.com \
--cc=junxiao.chang@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=vivek.kasireddy@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 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.