File: file.png (191 KB, 679x684)

191 KB PNG

This syscall has gotten too bloated. The really important ones (MADV_DONTNEED) can be taken care of with plain old mmap with MAP_FIXED, and the others (with the exception of MADV_HUGPAGE) probably never make a difference in the real world.

>>108023679
how can MADV_DONTNEED be replaced with MAP_FIXED?

>>108023724

bool madv_dontneed(void *addr, size_t len) {
    return MAP_FAILED !=
        mmap(addr, len, PROT_READ|PROT_WRITE,
            MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED, -1, 0);
}

>>108023751
??? how does that make sense at all? you're just mapping in new pages for no reason?

>>108023760
Mapping in new blank pages at the same address of the ones you don't want any more.

>>108023767
yes, again, you're still putting them into your RSS. not the same

>>108023774
No, because of lazy committing that only happens if you access those new pages.

>>108023795
i'd have to look into it more, but if that's the case, you might be right on that point
of course, there are still issues associated with your method
- it splits what was originally one mapping into three separate mappings
- there's no guarantee that what you want to MADV_DONTNEED is going to be an rw-p mapping
- the mapping could have had any number of other flags set which you've just blown away

>>108023836
>it splits what was originally one mapping into three separate mappings
The kernel merges identical adjacent mappings into one, so if it was surrounded by private anonymous RW maps before, it'll just be one after.
>there's no guarantee that what you want to MADV_DONTNEED is going to be an rw-p mapping
>the mapping could have had any number of other flags set which you've just blown away
Yes, you would need to adjust the flags to match the original.

>>108023907
>The kernel merges identical adjacent mappings into one
what the fuck? it does! that's so strange. i wonder why i was under a different impression. i guess i probably just did it at one point with different flags or something

bampu

one more bmup.....

>>108023158
Thanks, syscall anon!

>>108023679
>>108023751
MADV_DONTNEED is still useful for named regions (where it behaves as a more portable MADV_COLD), also MADV_WILLNEED and MADV_SEQUENTIAL/MADV_RANDOM are particularly useful for named regions backed by a spinning rust as well.

>>108026718
i'm a little sad that this one hasn't gotten many replies. i thought the content in the OP would make it especially interesting, but i guess maybe most people on /g/ don't have a ton of interest in these areas

>>108026874
It's a syscall that seems useless until you're writing for a platform where core is extremely constrained, then suddenly it shines. Maybe in the future more people will have that experience, but I don't think most desktop developers haven't had it in a while.

File: 1768631348004648.jpg (68 KB, 736x736)

68 KB JPG

>>108026913
oh, well i meant the other links i included in the OP, ahah...

>>108026913
>don't think most desktop developers haven't
God I'm fucking out of it tonight...

>>108026874
I just don't have much to contribute.

File: 1768200989948894.png (13 KB, 890x653)

13 KB PNG

>>108026987
i will forgive u just this once.....

>>108023158
>https://chao-tic.github.io/blog/2017/05/24/dirty-cow
man, that's a nice writeup, though I only understood like half of it lmao. I wish I understood more about kernel stuff, but I'm too lazy for that...

what syscall do i use to change my gender?

>>108027457

kill(0, SIGKILL);

>>108027457

switch_endian(2)

>>108027457
>>108027541
oh, or alternatively

swapon(2)
swapoff(2)
swapcontext(2)

>>108026855
I used it in something I did for work but it is so delicate it almost did bite me in the butt and I didn't do good enough testing. If you don't need it, it's best if you don't use it.

File: madvise.png (61 KB, 822x275)

61 KB PNG

>>108027879
I'm reading a lot about the Kernel and C right now and I've seen madvise used a bit here and there. I was trying to find the examples but all I can find right now is this, from OP3EP

>>108023158
MADV_GUARD_INSTALL is pretty neat. It's used to install fast guards into certain address ranges, and it can even install guards into file-backed mappings. Besides the obvious uses for guards, I assume that's how debuggers trap on memory access, that and a sigsegv signal handler.

>>108026874
I'm just very rarely memory limited, so I don't have much to tell about this syscall :/

>>108023158
cum deep inside kuromi

File: 1767456262539702.gif (29 KB, 220x269)

29 KB GIF

>>108030629
i hope you at least read the links i included as well !
>>108029281
isn't SIGSEGV a sort of guard in its own right? i guess explicit page guards protect against the case where two mappings end up right next to each other, though
>>108030826
n-no anon you can't do that it's illegal...

>>108023679
>MADV_HUGPAGE or MADV_POPULATE not making a difference in real world
you stupid man

>>108032458
be nice !

>>108031578
>i hope you at least read the links i included as well !
I did!! very interesting, and I didn't know about DONTNEED's weird behaviour, as I mostly just madvise(sequential).

>>108023158
Should I use madvise with a big pre allocated (but not backed) virtual space to make a ring buffer? Or is it better to just reallocate the buffer when resizing?

>>108031578
>isn't SIGSEGV a sort of guard in its own right?
Yes, but the point of guard pages is that when you try to access the address associated with the page, the program segfaults. Usually a guard page is just a page with PROT_NONE, but fast guards do virtual address trickery not only to speed up the guard itself but also allow the kernel to do its page tricks like page merging.