On Mon, Feb 23, 2004 at 01:09:06PM +0900, GOTO Masanori scribbled: [snip] > > the RLIMIT_RSS is in pages (as evidenced by [4,5] - PAGE_SHIFT is a macro > > that defines the number of bits by which a value must be left/right shifted > > in order to obtain memory size in pages/bytes respectively. It's > > architecture-specific). > > In 2.4 - yeah, exactly that's true. But look at 2.6. Rik's new patch > which is not still adopted (afaik) in linus tree is byte based. And And yet, both 2.6.x vanilla and the -mmX trees still treat RSS as the amout of pages. Take a look at fs/proc/task_mmu.c (even though RLIMIT_RSS is no longer used, the unit of mm->rss is still the pages) > RLIMIT_RSS is derived from BSD - and at least BSD and AIX use it as in > bytes. This means that kernel 2.4 is not compatible with generic > behavior - it's only 2.4 rule. I think this is kernel 2.4 potential According to the above file, this is not true (so far, at least). > incompatibility. Well, we cannot say this "in page" is kernel bug - > because RLIMIT_RSS is not defined in official documents. I agree, it's not a bug in the kernel. > > > However, if you can prove, by quoting the source, that libc behaves > > > different than what is written in our manpages, I'm willing to add > > > a note and pass it upstream, who may reject it, though. > > The comments in the bits/resource.h file confirm that libc thinks the > > amount is in bytes and I can't find any place where libc converts the value > > passed by the user to pages. Therefore, if somebody believes the libc > > docs/headers/sources, they will end up passing an incorrect value for the > > limit to the kernel (not that it matters on kernel v2.6) > > > > I've already reassigned Bug#234139 to libc6 and I'm Cc'ing this mail to the > > BTS since it corrects the mistake I made in the bug report. > > If you want to dig more, the manual should write this topic as "2.6 > has no RLIMIT_RSS, and 2.4 in page is linux specific behavior". True, RLIMIT_RSS has no meaning in 2.6 > As debian glibc maintainer point of view, this RLIMIT_RSS is affected > only on linux 2.4 and madvise() with MADVISE_WILLNEED flag. I wonder > this topic should be really written in GLIBC manual pages. Glibc is > primarily used in linux based systems, but not only for linux but also > hurd and so on. Well, since Debian is currently based on the 2.4 kernel, this is definitely misinformation for the user. I would say that either adding a note to that effect to the documentation or changing the description of the parameter to match the 2.4 reality would be in order. Of course, it should also be noted that the parameter has any meaning only for the 2.4 kernels, too. > So if there are any chances to modify glibc manual, the description > should be add as "implementation dependent" so that I still think > kernel 2.4 way is bad and should be corrected (however such chance > will never come, as you know). Well, it's not "bad" per se. According to SUS, the existence and meaning of RLIMIT_RSS is undefined, therefore an implementation has freedom to use whatever definition it wants. And I think it would be a good idea if the manpages and the libc docs agreed both with each other and the kernel :) regards, marek
Attachment:
signature.asc
Description: Digital signature