lkml.org 
[lkml]   [2002]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] remove hugetlb syscalls
David Mosberger-Tang wrote:

> But that's excactly the point. The hugepage interface returns a
> different kind of virtual memory. There are tons of programs out
> there using mmap(). If such a program gets fed a path to the
> hugepagefs, it might end up with huge pages without knowing anything
> about huge pages. For the most part, that might work fine, but it
> could lead to subtle failures.


Yeah, that was one of Linus's points about the syscalls, in a private
email. I mentioned how the new syscalls were in poor taste, when
existing syscalls would work fine, and he flamed me right back ;-)

One of his main points to me was exactly what you are elucidating:
there are subtle differences between normal pages and superpages that
are exposed to userland, and we should make that explicit [with the
syscalls] rather than hide it [with hugetlbfs/mmap/etc.]. So I think
this is further indication Linus has a very valid point ;-)

However, that said, I think hugetlbfs will almost always get used in
preference to the syscalls, so leaving them in may be more a statement
of technical correctness/cleanliness than anything else.

[tangent warning]
This whole hugetlb affair is unfortunately pretty ugly, and this thread
is just one component of that. All these discussions occurred off-list,
and it's _still_ a political football. Sigh. I just hope that the
furor dies down soon, that smart technical [apolitical] decisions are
made, and future discussions are at least CC'd to lkml.

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:0.063 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site