On Thu, Nov 17, 2016 at 10:54 AM, Corinna Vinschen <[email protected]> wrote: > On Nov 16 15:51, Erik Bray wrote: >> On Wed, Nov 16, 2016 at 3:01 PM, Eric Blake <[email protected]> wrote: >> > On 11/16/2016 07:56 AM, Erik Bray wrote: >> > >> >>> There is no good reason to use the non-POSIXy page size. It doesn't >> >>> help you in the least for any pagesize-related functionality. Mmap >> >>> as well as malloc and friends only work with _SC_PAGESIZE sized pages. >> >>> >> >>> It sounds as if you're looking for a solution for which there's no >> >>> problem... >> >> >> >> >> >> FWIW the background here is that I'm working on porting psutil [1] to >> >> Cygwin, and trying to accomplish as much as *possible* through the >> >> POSIX interfaces without having to fall back on the Windows API. It's >> >> actually a great exercise in what is and isn't possible with Cygwin :) >> >> >> >> In this case I was trying to compute process memory usage from >> >> /proc/<pid>/statm which gives values in page counts, so I need the >> >> page size (the actual page size) to compute the values in bytes. >> > >> > If /proc/<pid>/statm is reporting memory in multiples that are not the >> > POSIX _SC_PAGESIZE, that is a bug in the statm file emulation that >> > should be fixed there. >> >> So then something like that attached (untested) patch should work, >> though it made statm inconsistent with what is reported in >> /proc/<pid>/status which reports memory in multiples of page size. So >> that has to be patched as well. > > Patches applied as obvious, thank you. > >> This of course leads to memory reporting that is inconsistent with >> what Windows says. But I guess if that's "normal" in Cygwin (for the >> reasons stated by Corinna) then it's an acceptable trade-off? > > It is. From the POSIX POV we have a 64K page size, from the Windows > POV we have a bastard of 4K pages which can only be allocated in > chunks of 16. The latter simply doesn't fly well with POSIX > assumptions. > > Since native Windows tools don't see the Cygwin internal assumptions, > it doesn't matter, unless you mix Windows and Cygwin memory functions. > Which, honestly, should only be done by Cygwin itself.
That works for me. It makes things a bit tricky in my particular case, but I admit it's an unusual one, and now that I'm aware of the issue I can work with it. Thanks for accepting the patch. Erik
