On Mon, 30 Mar 2015, KOSAKI Motohiro wrote:
> On Thu, Mar 26, 2015 at 10:08 AM, Eric B Munson wrote:
> > On 03/26/2015 07:56 AM, Davide Libenzi wrote:
> >> On Wed, 25 Mar 2015, David Rientjes wrote:
> >>
> >>> I looked at this thread at http://marc.info/?t=14139250881
> >>> since I didn't have
On Thu, Mar 26, 2015 at 10:08 AM, Eric B Munson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/26/2015 07:56 AM, Davide Libenzi wrote:
>> On Wed, 25 Mar 2015, David Rientjes wrote:
>>
>>> I looked at this thread at http://marc.info/?t=14139250881
>>> since I didn't have it
On Thu, 26 Mar 2015, David Rientjes wrote:
> On Thu, 26 Mar 2015, Davide Libenzi wrote:
>
> > > Yes, this munmap() behavior of lengths <= hugepage_size - PAGE_SIZE for a
> > > hugetlb vma is long standing and there may be applications that break as
> > > a
> > > result of changing the behavior
Might be too late in this thread, but in case you are going to continue and/or
repost:
[CC += linux-...@vger.kernel.org]
(also linux-man and Michael to match my other reply)
Since this is a kernel-user-space API change, please CC linux-api@. The
kernel source file Documentation/SubmitChecklis
On 03/26/2015 08:39 PM, Davide Libenzi wrote:
> On Thu, 26 Mar 2015, David Rientjes wrote:
>
>> Yes, this munmap() behavior of lengths <= hugepage_size - PAGE_SIZE for a
>> hugetlb vma is long standing and there may be applications that break as a
>> result of changing the behavior: a database t
On Thu, 26 Mar 2015, Davide Libenzi wrote:
> > Yes, this munmap() behavior of lengths <= hugepage_size - PAGE_SIZE for a
> > hugetlb vma is long standing and there may be applications that break as a
> > result of changing the behavior: a database that reserves all allocated
> > hugetlb memory
On Thu, 26 Mar 2015, David Rientjes wrote:
> Yes, this munmap() behavior of lengths <= hugepage_size - PAGE_SIZE for a
> hugetlb vma is long standing and there may be applications that break as a
> result of changing the behavior: a database that reserves all allocated
> hugetlb memory with mma
On Thu, 26 Mar 2015, Davide Libenzi wrote:
> > I looked at this thread at http://marc.info/?t=14139250881 since I
> > didn't have it in my mailbox, and I didn't get a chance to actually run
> > your test code.
> >
> > In short, I think what you're saying is that
> >
> > ptr = mmap(...,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/26/2015 07:56 AM, Davide Libenzi wrote:
> On Wed, 25 Mar 2015, David Rientjes wrote:
>
>> I looked at this thread at http://marc.info/?t=14139250881
>> since I didn't have it in my mailbox, and I didn't get a chance
>> to actually run your t
On Wed, 25 Mar 2015, David Rientjes wrote:
> I looked at this thread at http://marc.info/?t=14139250881 since I
> didn't have it in my mailbox, and I didn't get a chance to actually run
> your test code.
>
> In short, I think what you're saying is that
>
> ptr = mmap(..., 4KB, ..., M
On Wed, 25 Mar 2015, Davide Libenzi wrote:
> > When you say "tracking back to 3.2.x", I think you mean you've tried as
> > far back as 3.2.x and found the same behaviour, but not tried further?
> >
> > From the source, it looks like this is unchanged since MAP_HUGETLB was
> > introduced in 2.6.32
On Wed, 25 Mar 2015, Hugh Dickins wrote:
> When you say "tracking back to 3.2.x", I think you mean you've tried as
> far back as 3.2.x and found the same behaviour, but not tried further?
>
> From the source, it looks like this is unchanged since MAP_HUGETLB was
> introduced in 2.6.32. And is th
On Wed, 22 Oct 2014, Davide Libenzi wrote:
> [Resending with proper CC list suggested by Andrew]
I have recently been reminded of this languishing in my inbox ;)
(along with many others that I won't get to answer so quickly).
And in turn it reminds me of an older from Joern, who was annoyed
that
13 matches
Mail list logo
