On Wed, 31 Oct 2007, Paul Jackson wrote:
> With the mode bit as in my patch, there are fewer places in the user
> code that have to be gotten just right. With your way, each and
> every mbind and *_mempolicy call has to be hacked with the new flag
> if one is going to use the new nodemask bit numbering.
That code is going to have to be hacked anyway to use the new nodemask
semantics, so it can easily add a flag to the set_mempolicy() call for the
system-wide node numbering. This then only requires a small addition to
the documentation: use MPOL_F_MODE_SYS_WIDE for system-wide node numbering
that isn't constrained to your cpuset.
> Some of these
> calls might be inside other routines or libraries that aren't readily
> available to be examined or changed. If you miss one, or forget to
> add one when adding more mbind or *_mempolicy calls in the future,
> then you have a nasty lurking hidden performance bug due to misplaced
> pages in certain configurations. That too is a serious maintenance
> nightmare, as I've already tried to describe.
>
That's a very legitimate concern, but those libraries will eventually need
to be made to support this new extention anyway. They will be modified
just like we're modifying the kernel once people want to start using the
different nodemask semantics. As mempolicy modes become more popular,
those libraries are going to start accepting custom mode flags to pass to
their set_mempolicy() wrappers that will get OR'd with the mempolicy mode
that is used. It will be the natural progression of how mempolicies are
supported in userspace.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
