I hate to resurrect this thread, but I would like to add hugetlb support
to memfd_create. This is for JVM garbage collection as discussed in
this thread [1].
Adding hugetlb support to memfd_create, means that memfd_create will take
a flag something like MFD_HUGETLB. And, if a user wants hugetlb
I hate to resurrect this thread, but I would like to add hugetlb support
to memfd_create. This is for JVM garbage collection as discussed in
this thread [1].
Adding hugetlb support to memfd_create, means that memfd_create will take
a flag something like MFD_HUGETLB. And, if a user wants hugetlb
On Thu, Apr 13, 2017 at 11:32:09AM +0530, Aneesh Kumar K.V wrote:
> > +#define SHM_HUGE_SHIFT 26
> > +#define SHM_HUGE_MASK 0x3f
> > +#define SHM_HUGE_2MB (21 << SHM_HUGE_SHIFT)
> > +#define SHM_HUGE_8MB (23 << SHM_HUGE_SHIFT)
> > +#define SHM_HUGE_1GB (30 <<
On Thu, Apr 13, 2017 at 11:32:09AM +0530, Aneesh Kumar K.V wrote:
> > +#define SHM_HUGE_SHIFT 26
> > +#define SHM_HUGE_MASK 0x3f
> > +#define SHM_HUGE_2MB (21 << SHM_HUGE_SHIFT)
> > +#define SHM_HUGE_8MB (23 << SHM_HUGE_SHIFT)
> > +#define SHM_HUGE_1GB (30 <<
Matthew Wilcox writes:
> On Tue, Mar 28, 2017 at 09:55:13AM -0700, Davidlohr Bueso wrote:
>> Do we have any consensus here? Keeping SHM_HUGE_* is currently
>> winning 2-1. If there are in fact users out there computing the
>> value manually, then I am ok with keeping it and
Matthew Wilcox writes:
> On Tue, Mar 28, 2017 at 09:55:13AM -0700, Davidlohr Bueso wrote:
>> Do we have any consensus here? Keeping SHM_HUGE_* is currently
>> winning 2-1. If there are in fact users out there computing the
>> value manually, then I am ok with keeping it and properly exporting
>>
On Wed, Apr 12, 2017 at 09:18:29AM -0700, Davidlohr Bueso wrote:
> On Thu, 30 Mar 2017, Michal Hocko wrote:
>
> > On Wed 29-03-17 10:45:14, Andi Kleen wrote:
> > > On Wed, Mar 29, 2017 at 10:06:25AM +0200, Michal Hocko wrote:
> > > >
> > > > Do we actually have any users?
> > >
> > > Yes this
On Wed, Apr 12, 2017 at 09:18:29AM -0700, Davidlohr Bueso wrote:
> On Thu, 30 Mar 2017, Michal Hocko wrote:
>
> > On Wed 29-03-17 10:45:14, Andi Kleen wrote:
> > > On Wed, Mar 29, 2017 at 10:06:25AM +0200, Michal Hocko wrote:
> > > >
> > > > Do we actually have any users?
> > >
> > > Yes this
On Wed, Apr 12, 2017 at 09:18:29AM -0700, Davidlohr Bueso wrote:
> On Thu, 30 Mar 2017, Michal Hocko wrote:
>
> > On Wed 29-03-17 10:45:14, Andi Kleen wrote:
> > > On Wed, Mar 29, 2017 at 10:06:25AM +0200, Michal Hocko wrote:
> > > >
> > > > Do we actually have any users?
> > >
> > > Yes this
On Wed, Apr 12, 2017 at 09:18:29AM -0700, Davidlohr Bueso wrote:
> On Thu, 30 Mar 2017, Michal Hocko wrote:
>
> > On Wed 29-03-17 10:45:14, Andi Kleen wrote:
> > > On Wed, Mar 29, 2017 at 10:06:25AM +0200, Michal Hocko wrote:
> > > >
> > > > Do we actually have any users?
> > >
> > > Yes this
On Thu, 30 Mar 2017, Michal Hocko wrote:
On Wed 29-03-17 10:45:14, Andi Kleen wrote:
On Wed, Mar 29, 2017 at 10:06:25AM +0200, Michal Hocko wrote:
>
> Do we actually have any users?
Yes this feature is widely used.
Considering that none of SHM_HUGE* has been exported to the userspace
On Thu, 30 Mar 2017, Michal Hocko wrote:
On Wed 29-03-17 10:45:14, Andi Kleen wrote:
On Wed, Mar 29, 2017 at 10:06:25AM +0200, Michal Hocko wrote:
>
> Do we actually have any users?
Yes this feature is widely used.
Considering that none of SHM_HUGE* has been exported to the userspace
On Wed 29-03-17 10:45:14, Andi Kleen wrote:
> On Wed, Mar 29, 2017 at 10:06:25AM +0200, Michal Hocko wrote:
> > On Tue 28-03-17 10:54:08, Matthew Wilcox wrote:
> > > On Tue, Mar 28, 2017 at 09:55:13AM -0700, Davidlohr Bueso wrote:
> > > > Do we have any consensus here? Keeping SHM_HUGE_* is
On Wed 29-03-17 10:45:14, Andi Kleen wrote:
> On Wed, Mar 29, 2017 at 10:06:25AM +0200, Michal Hocko wrote:
> > On Tue 28-03-17 10:54:08, Matthew Wilcox wrote:
> > > On Tue, Mar 28, 2017 at 09:55:13AM -0700, Davidlohr Bueso wrote:
> > > > Do we have any consensus here? Keeping SHM_HUGE_* is
On Wed, Mar 29, 2017 at 10:06:25AM +0200, Michal Hocko wrote:
> On Tue 28-03-17 10:54:08, Matthew Wilcox wrote:
> > On Tue, Mar 28, 2017 at 09:55:13AM -0700, Davidlohr Bueso wrote:
> > > Do we have any consensus here? Keeping SHM_HUGE_* is currently
> > > winning 2-1. If there are in fact users
On Wed, Mar 29, 2017 at 10:06:25AM +0200, Michal Hocko wrote:
> On Tue 28-03-17 10:54:08, Matthew Wilcox wrote:
> > On Tue, Mar 28, 2017 at 09:55:13AM -0700, Davidlohr Bueso wrote:
> > > Do we have any consensus here? Keeping SHM_HUGE_* is currently
> > > winning 2-1. If there are in fact users
On Tue 28-03-17 10:54:08, Matthew Wilcox wrote:
> On Tue, Mar 28, 2017 at 09:55:13AM -0700, Davidlohr Bueso wrote:
> > Do we have any consensus here? Keeping SHM_HUGE_* is currently
> > winning 2-1. If there are in fact users out there computing the
> > value manually, then I am ok with keeping it
On Tue 28-03-17 10:54:08, Matthew Wilcox wrote:
> On Tue, Mar 28, 2017 at 09:55:13AM -0700, Davidlohr Bueso wrote:
> > Do we have any consensus here? Keeping SHM_HUGE_* is currently
> > winning 2-1. If there are in fact users out there computing the
> > value manually, then I am ok with keeping it
On Tue, Mar 28, 2017 at 09:55:13AM -0700, Davidlohr Bueso wrote:
> Do we have any consensus here? Keeping SHM_HUGE_* is currently
> winning 2-1. If there are in fact users out there computing the
> value manually, then I am ok with keeping it and properly exporting
> it. Michal?
Well, let's see
On Tue, Mar 28, 2017 at 09:55:13AM -0700, Davidlohr Bueso wrote:
> Do we have any consensus here? Keeping SHM_HUGE_* is currently
> winning 2-1. If there are in fact users out there computing the
> value manually, then I am ok with keeping it and properly exporting
> it. Michal?
Well, let's see
Sorry, forgot to add Anshuman.
On Tue, 28 Mar 2017, Davidlohr Bueso wrote:
Do we have any consensus here? Keeping SHM_HUGE_* is currently
winning 2-1. If there are in fact users out there computing the
value manually, then I am ok with keeping it and properly exporting
it. Michal?
Thanks,
Sorry, forgot to add Anshuman.
On Tue, 28 Mar 2017, Davidlohr Bueso wrote:
Do we have any consensus here? Keeping SHM_HUGE_* is currently
winning 2-1. If there are in fact users out there computing the
value manually, then I am ok with keeping it and properly exporting
it. Michal?
Thanks,
Do we have any consensus here? Keeping SHM_HUGE_* is currently
winning 2-1. If there are in fact users out there computing the
value manually, then I am ok with keeping it and properly exporting
it. Michal?
Thanks,
Davidlohr
Do we have any consensus here? Keeping SHM_HUGE_* is currently
winning 2-1. If there are in fact users out there computing the
value manually, then I am ok with keeping it and properly exporting
it. Michal?
Thanks,
Davidlohr
On Wed 08-03-17 09:06:01, Davidlohr Bueso wrote:
> The SHM_HUGE_* stuff was introduced in:
>
>42d7395feb5 (mm: support more pagesizes for MAP_HUGETLB/SHM_HUGETLB)
>
> It unnecessarily adds another layer, specific to sysv shm, without
> anything special about it: the macros are identical to
On Wed 08-03-17 09:06:01, Davidlohr Bueso wrote:
> The SHM_HUGE_* stuff was introduced in:
>
>42d7395feb5 (mm: support more pagesizes for MAP_HUGETLB/SHM_HUGETLB)
>
> It unnecessarily adds another layer, specific to sysv shm, without
> anything special about it: the macros are identical to
On 03/09/2017 01:09 AM, Andi Kleen wrote:
>> One example of the problems with extra layers what this patch fixes:
>> mmap_pgoff() should never be using SHM_HUGE_* logic. This was
>> introduced by:
>>
>>091d0d55b28 (shm: fix null pointer deref when userspace specifies invalid
>> hugepage size)
On 03/09/2017 01:09 AM, Andi Kleen wrote:
>> One example of the problems with extra layers what this patch fixes:
>> mmap_pgoff() should never be using SHM_HUGE_* logic. This was
>> introduced by:
>>
>>091d0d55b28 (shm: fix null pointer deref when userspace specifies invalid
>> hugepage size)
> One example of the problems with extra layers what this patch fixes:
> mmap_pgoff() should never be using SHM_HUGE_* logic. This was
> introduced by:
>
>091d0d55b28 (shm: fix null pointer deref when userspace specifies invalid
> hugepage size)
>
> It is obviously harmless but lets just
> One example of the problems with extra layers what this patch fixes:
> mmap_pgoff() should never be using SHM_HUGE_* logic. This was
> introduced by:
>
>091d0d55b28 (shm: fix null pointer deref when userspace specifies invalid
> hugepage size)
>
> It is obviously harmless but lets just
The SHM_HUGE_* stuff was introduced in:
42d7395feb5 (mm: support more pagesizes for MAP_HUGETLB/SHM_HUGETLB)
It unnecessarily adds another layer, specific to sysv shm, without
anything special about it: the macros are identical to the MAP_HUGE_*
stuff, which in turn does correctly describe
The SHM_HUGE_* stuff was introduced in:
42d7395feb5 (mm: support more pagesizes for MAP_HUGETLB/SHM_HUGETLB)
It unnecessarily adds another layer, specific to sysv shm, without
anything special about it: the macros are identical to the MAP_HUGE_*
stuff, which in turn does correctly describe
32 matches
Mail list logo