This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Return the correct value for sysconf(_SC_PAGESIZE)


On Thu, Nov 17, 2016 at 10:54 AM, Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:
> On Nov 16 15:51, Erik Bray wrote:
>> On Wed, Nov 16, 2016 at 3:01 PM, Eric Blake <eblake@redhat.com> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]