On Fri, Oct 27, 2017 at 04:29:16PM +0200, Vlastimil Babka wrote:
> On 10/24/2017 09:41 AM, C.Wehrmeyer wrote:
> > On 2017-10-23 20:02, Michal Hocko wrote:
> >> On Mon 23-10-17 19:52:27, C.Wehrmeyer wrote:
> >> [...]
> or you can mmap a larger block and
> munmap the initial unaligned part.
On 10/27/2017 07:29 AM, Vlastimil Babka wrote:
> On 10/24/2017 09:41 AM, C.Wehrmeyer wrote:
>> On 2017-10-23 20:02, Michal Hocko wrote:
>>> On Mon 23-10-17 19:52:27, C.Wehrmeyer wrote:
>>> [...]
>>
>> 1. Provide a flag to mmap, which might be something different from
>> MAP_HUGETLB. After all your
On 10/24/2017 09:41 AM, C.Wehrmeyer wrote:
> On 2017-10-23 20:02, Michal Hocko wrote:
>> On Mon 23-10-17 19:52:27, C.Wehrmeyer wrote:
>> [...]
or you can mmap a larger block and
munmap the initial unaligned part.
>>>
>>> And how is that supposed to be transparent? When I hear "transparent
On 2017-10-24 10:12, Michal Hocko wrote:
On Tue 24-10-17 09:41:46, C.Wehrmeyer wrote:
[...]
1. Provide mmap with some sort of flag (which would be redundant IMHO) in
order to churn out properly aligned pages (not transparent, but the current
MAP_HUGETLB flag isn't either).
You can easily imple
On Tue 24-10-17 09:41:46, C.Wehrmeyer wrote:
[...]
> 1. Provide mmap with some sort of flag (which would be redundant IMHO) in
> order to churn out properly aligned pages (not transparent, but the current
> MAP_HUGETLB flag isn't either).
You can easily implement such a thing in userspace. In fact
On 2017-10-23 20:51, Mike Kravetz wrote:
> [...]
Well at least this has a built in fall back mechanism. When using hugetlb(fs)
pages, you would need to handle the case where mremap fails due to lack of
configured huge pages.
You're missing the point. I never asked for a fall-back mechanism, ev
On 2017-10-23 20:02, Michal Hocko wrote:
On Mon 23-10-17 19:52:27, C.Wehrmeyer wrote:
[...]
or you can mmap a larger block and
munmap the initial unaligned part.
And how is that supposed to be transparent? When I hear "transparent" I
think of a mechanism which I can put under a system so that
On 10/23/2017 10:52 AM, C.Wehrmeyer wrote:
> On 2017-10-23 18:57, Michal Hocko wrote:
>> On Mon 23-10-17 18:46:59, C.Wehrmeyer wrote:
>>> On 23-10-17 18:13, Michal Hocko wrote:
On Mon 23-10-17 16:00:13, C.Wehrmeyer wrote:
> And just to be very sure I've added:
>
> if (madvise(buf1,
On Mon 23-10-17 19:52:27, C.Wehrmeyer wrote:
[...]
> > or you can mmap a larger block and
> > munmap the initial unaligned part.
>
> And how is that supposed to be transparent? When I hear "transparent" I
> think of a mechanism which I can put under a system so that it benefits from
> it, while th
On 2017-10-23 18:57, Michal Hocko wrote:
On Mon 23-10-17 18:46:59, C.Wehrmeyer wrote:
On 23-10-17 18:13, Michal Hocko wrote:
On Mon 23-10-17 16:00:13, C.Wehrmeyer wrote:
And just to be very sure I've added:
if (madvise(buf1,ALLOC_SIZE_1,MADV_HUGEPAGE)) {
errno_tmp = errno;
On Mon 23-10-17 18:46:59, C.Wehrmeyer wrote:
> On 23-10-17 18:13, Michal Hocko wrote:
> > On Mon 23-10-17 16:00:13, C.Wehrmeyer wrote:
> > > And just to be very sure I've added:
> > >
> > > if (madvise(buf1,ALLOC_SIZE_1,MADV_HUGEPAGE)) {
> > > errno_tmp = errno;
> > > fprintf(std
On 23-10-17 18:13, Michal Hocko wrote:
On Mon 23-10-17 16:00:13, C.Wehrmeyer wrote:
And just to be very sure I've added:
if (madvise(buf1,ALLOC_SIZE_1,MADV_HUGEPAGE)) {
errno_tmp = errno;
fprintf(stderr,"madvise: %u\n",errno_tmp);
goto out;
}
/*Make sure the mapping
On Mon 23-10-17 16:00:13, C.Wehrmeyer wrote:
[...]
> > And that is what we have THP for...
>
> Then I might have been using it incorrectly? I've been digging through
> Documentation/vm/transhuge.txt after your initial pointing out, and verified
> that the kernel uses THPs pretty much always, witho
On 2017-10-23 14:41, Michal Hocko wrote:
On Mon 23-10-17 14:22:30, C.Wehrmeyer wrote:
On 2017-10-23 13:42, Michal Hocko wrote:
I do not remember any such a request either. I can see some merit in the
described use case. It is not specific on why hugetlb pages are used for
the allocator memory b
On Mon 23-10-17 14:22:30, C.Wehrmeyer wrote:
> On 2017-10-23 13:42, Michal Hocko wrote:
> > I do not remember any such a request either. I can see some merit in the
> > described use case. It is not specific on why hugetlb pages are used for
> > the allocator memory because that comes with it own i
On 2017-10-23 13:42, Michal Hocko wrote:
I do not remember any such a request either. I can see some merit in the
described use case. It is not specific on why hugetlb pages are used for
the allocator memory because that comes with it own issues.
That is yet for the user to specify. As of now h
On Fri 20-10-17 15:42:25, Mike Kravetz wrote:
> On 10/19/2017 12:34 AM, C.Wehrmeyer wrote:
[...]
> > As for the specific use case: I've written my own allocator that is
> > not bound on the same limitations that usual malloc/realloc/free
> > allocators are bound. As such I want to be able to elimin
On 10/19/2017 12:34 AM, C.Wehrmeyer wrote:
> I apologise in case this message is going to arrive multiple times at the
> mailing list. I've had connection problems this morning while trying to push
> it through regardless, but it might or might not have been sent properly. I'm
> sorry for the in
18 matches
Mail list logo
