Messages in this thread | | | Date | Thu, 10 Nov 2005 14:06:21 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] Expose SHM_HUGETLB in shmctl(id, IPC_STAT, ...) |
| |
Arun Sharma <arun.sharma@google.com> wrote: > > Andrew Morton wrote: > > >>The man page on my system says: > >> > >> unsigned short mode; /* Permissions + SHM_DEST and > >> SHM_LOCKED flags */ > >> > >>I looked for a precendent before sending the patch and thought that > >>SHM_LOCKED was a good one. > >> > > > > > > hm, OK. But an app could still do > > > > if (mode == 0666|SHM_LOCKED) > > > > I'd argue that the app should really be doing (perm.mode & 0777 = 0666)
I find your faith in your fellow programmers to be trluy inspirational ;)
> > > > How important is this feature? > > Without this feature, an application has no way to figure out if a given > segment is hugetlb or not. Applications need to know this to be able to > handle alignment issues properly. > > Also, if the flag is exported via ipcs, the system administrator would > have a better idea about how the hugetlb pages she configured on the > system are getting used. >
I'd suggest that any API which allows us to query the hugeness of a piece of memory should also work for mmap(hugetld_fd...). IOW: this capability shouldn't be restricted to sysv shm areas.
I can't think of any syscall which can be sanely overloaded for this.
The most general way of exposing this info would be to export it in /proc/pid/maps in some back-compatible manner.
And once I've lost the "oh oh we'd need to write 100 lines of userspace code for that" bunfight I'd say add a new syscall sys_query_pagesize(void *addr) which returns the size of the page which backs `addr'.
But then again, if it was possible to write 100 lines of userspace code, we wouldn't need this capability at all. I bet if the userspace guys tried a bit harder they'd work out a way of teaching their applications to remember what they did. - 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/
| |