<bslsk05>
lwn.net: Maximal min() and max() [LWN.net]
<nikolar>
btw i know you're ripping off linux, buy you don't have to rip off their bugs and problems
<nikolar>
yes i know of that article
<heat_>
this is not a bug, this is a C bug
<nikolar>
it's not
<heat_>
this could very trivially be written in completely standard C++ using TEMPLATES
<heat_>
but C insists in poor man's templates: cpp macros and copious use of __typeof__
<heat_>
C23 has auto at least
<nikolar>
which is the same as typeof so why does that matter
<heat_>
__typeof__(x) was extra template expansions
<nikolar>
sure
<heat_>
i think they ended up going with __auto_type
<nikolar>
who did
<heat_>
linus
<nikolar>
i don't follow
<heat_>
i was CC'd on the email threads
<nikolar>
right fun
<Matt|home>
o\
<heat_>
i think the min() and max() macros ended up replacing those __typeof__ with __auto_type
<heat_>
but it was ultimately completely non trivial because of course C constant expressions are very limit and hard to work with
<nikolar>
well if it fixes the problem then good
<heat_>
it does not fix the problem, don't worry
<nikolar>
lol
<nikolar>
well the macros are a mess to being with
<nikolar>
begin
<nikolar>
*those
<heat_>
sadly the C23 constexpr still sucks and there are no templates to speak of
<heat_>
so until then, many-MB macroen it is
<nikolar>
why do you expect c to ever have teplates
<heat_>
because they're useful and _generally_ C compilers already support it through their C++ driver
<nikolar>
so just put more shit from c++ into c
<heat_>
C would be _a lot_ easier if the language actually reflected what the compiler can already do
<nikolar>
makes sense to me
<nikolar>
you clearly don't want to use c, so why are you trying to
<heat_>
i want to use C because it's a nice common ABI, kernel tooling already supports it
<heat_>
i'm under no illusion of it being the best language ever
<nikolar>
it is
<nikolar>
better than c++
<heat_>
i'm also shifting to C because it reflects my coding style a little better than C++
<heat_>
and it suits the kernel space a little better
<nikolar>
and that's why you want all of the c++ crap in c
<heat_>
oh yes definitely i want ALL of the C++ crap
<heat_>
i want to join the committee and add classes
<heat_>
C ranges are going to be rad
<nikolar>
i mean you did just say you want templates in c
<nikolar>
but ok
<nikolar>
and let's be real templates are the messiest part of c++
<heat_>
templates can be nice and simple if you keep them nice and simple
<heat_>
they are almost literally the language's preprocessor
<nikolar>
sure
<heat_>
(and the same applies to cpp)
<nikolar>
because that's how everyone is using them
<heat_>
are your macros expanding to 50MB of code?
<nikolar>
No
<heat_>
we should remove macros because linux's expand to 50MB at a time
<nikolar>
That's not a fair comparison at all
<nikolar>
Your average templates c++ program expands to a heck of a lot of code compared to your average c code with macros
<heat_>
it's a somewhat similar feature you can abuse (and you keep the pieces, namingly terrible compile time)
<heat_>
does not mean it shouldn't be there
<heat_>
i would wager the average C++ program is of lower quality than the average C program
<heat_>
at least when taking into account Real Projects(tm)
<nikolar>
Well c doesn't have an equivalent to boost, I'll just say that
<heat_>
then there's the subset of people that think compile time is super ok to sacrifice in exchange for extra safety. i don't intersect with those
<nikolar>
Well anyway, it's late
<nikolar>
Good night
<heat_>
night
<heat_>
i just want to say that i don't expect the full template shebang to be moved into C any time soon, but very simple template expansions sounds somewhat likely. like they did with constexpr functions (adding a really simple variant at first)
<nikolar>
And what I want to say is, if you want c++ features, use c++
<heat_>
do you really think C23 is perfect? no new changes allowed?
<heat_>
i dont want you to answer me because this discussion really isn't productive, but think about it
<heat_>
i generally think things should move forward
<nikolar>
No i very much dislikes c23, but I don't think templates belong in c
<nikolar>
Like why are we discussing c becoming c++ from 30 years ago
<heat_>
because what was avant-garde 30 years ago is conservative now
<nikolar>
So c should just become c++
<nikolar>
Well boy do I have solution for you, it's called c++
<heat_>
yes templates were indeed invented by bjarne stringsoup while he was on the toilet
<nikolar>
No, neither were they avant garde 30 years ago
linearcannon has quit [Read error: Connection reset by peer]
cultpony has quit [Ping timeout: 248 seconds]
cultpony has joined #osdev
kof673 has quit [Quit: q]
zhiayang has quit [Quit: oof.]
zhiayang has joined #osdev
netbsduser has joined #osdev
netbsduser has quit [Ping timeout: 255 seconds]
vdamewood has joined #osdev
sly has joined #osdev
sly has quit [Quit: Leaving]
GeDaMo has joined #osdev
sly has joined #osdev
sly has quit [Quit: Leaving]
sly has joined #osdev
stolen has joined #osdev
osdev199 has joined #osdev
<osdev199>
Hi, in my nvme driver, while creating the first i/o completion queue, it is failing with the status code 2 (Invalid Field in Command). I have double checked my commands and still I can't figure out which cmd is invalid.
<mjg>
^5 aka high five is not some #mm invention mofo
<nikolar>
very nice sortie
<mjg>
oh haha
<mjg>
sortie: that guy is an ass
<heat_>
sortie, i mean it's an openbsd dev why would you care
<sortie>
Fame and fortune
<heat_>
dua lipa is in love with you
<heat_>
who cares about guenther's opinion?
<mjg>
for better or worse the real answer is: linux is NOT going to get the feature, so it's best to spend time on something else
<heat_>
dua@openbsd.org :eyes emoji:
<sortie>
heat_: It was a goal of mine to be casually dismissed like Hurd or Minix
<nikolar>
mjg: and rationale for that
<mjg>
nikolar: i don't remember, apart from strongly saying "NAK". sortie might?
<Ermine>
:(
<mjg>
heat_: where is the slab patch mofer
<sortie>
Guenther does make a really good point. Preserving FD_CLOFORK across execve seems iffy and probably a bad idea. Especially if you implement setuid/setgid executables (I do not), that seems like a basic vulnerability where you set FD_CLOFORK on fd 0, 1, 2, and if it forks, see if it misbehaves in an exploitable manner
<mjg>
the cloroform flag is a shit hack around the real problem
<heat_>
nikolar, mjg: the rationale is that it's wasteful to allocate a second bitmap for O_CLOFORK and they don't think this is useful enough for it
<nikolar>
ah ok
<heat_>
mjg, uhh i'll Work On It later
<heat_>
sortie, btw you're on right track, you'll be casually dismissed like openbsd and netbsd in no time
<sortie>
heat_: Man that's the dream
<sortie>
Being used in the same sentence that also casually disregards FreeBSD
<sortie>
First they ignore you, then they compare your uselessness with Minix, then they disregard you and FreeBSD, then you win
<nikolar>
indeed
<mjg>
:))
<mjg>
there was the original quote hanging out in internal postes at red hat offices
<mjg>
it was misattributed to gandhi
<mjg>
that was funny
<sortie>
Recently I've been working on running my operating system upgrade-on-boot mechanism in a safer more well defined environment. Basically I do upgrades by installing a whole new system in /sysmerge and then pointing the bootloader config to boot from there rather than /. It then installs onto / and removes /sysmerge and does a soft reinit into / booting the newly upgraded system.
<heat_>
sortie, note i said openbsd and netbsd
<mjg>
8/
<heat_>
freebsd is a step up
<mjg>
that's rather low tech 90s idea
<mjg>
real chads have COW filesystems
<mjg>
you boot into a snapshot and bam, updated
<sortie>
The big problem is that /sysmerge is a weird environment. It may be ABI incompatible with /. I do not want to mix the ABIs since I'm running the new kernel at this point. I'm being careful in init and sysmerge --booting to do this without executing other programs and such.
<heat_>
no i have a good old block based filesystem with block groups and extents
<mjg>
wanna revert? you boot into an older one
<heat_>
and a JOURNAL
<heat_>
mon what filesystem do you run on linux?
<heat_>
zfs?
<mjg>
lol i run the one which was rejected by the folio man
<sortie>
In the future I'll also have a lot of fun making it use /sysmertge/lib/ld.so instead when I have dynamic linking too
<mjg>
who said my setup is great
<heat_>
huh?
<mjg>
here is an example where fucking SOLARIS and FREEBSD do things right: boot environments on zfs
<mjg>
credit to solaris for coming up with it, freebsd merely stole it
<heat_>
did the folio man ever reject a filesystem?
<sortie>
The issue is that it's all one big special case in init and it caused complexity and room for error when I expand this system in the future
<mjg>
heat_: dude said he was convering ext4 to use folios and moved to xfs after reading the code
<heat_>
lol
<heat_>
that's ironic because xfs is markedly NOT linux code
<mjg>
i don't think it's very ironic. the stuff which works on linux is all ported over or reasonably new
<heat_>
has proprietary unix vibes all over it
<mjg>
the old stuff is all shite
<sortie>
My solution: I made it a real feature in init(8) kinda. I have a new --static-prefix=/sysmerge that makes init use the programs and binaries and other static operating system data from that location when setting up PATH and such, but use the local files from /etc and /var/log and such
<heat_>
ext4 definitely works though?
<mjg>
i already ranted about it, it's a primitive shite fs, i only se use it cause i can't be fucked to migrate
<sortie>
Now init is better aware of this as a real solution without special case hacks. It also means that I can run sysmerge --booting as a real daemon which means it's logged to /var/log/sysmerge.log.
<heat_>
i wouldn't call the ext4 code shit, there was a lot of shittier code elsewhere
<mjg>
i don't know internals, i know some of the feature set and it's stale af
<heat_>
like mmap was terribad before the widespread refactoring, swap is dogshit
<heat_>
right
<sortie>
Overall it's a nice refactor that removed a weird special environment and made it a more supported (if weird) environment and the special case was removed from init. \o/
<sortie>
Plus now the upgrades are logged
<heat_>
what would you migrate to? zfs? btrfs? xfs?
<mjg>
sortie: so at the end of the day updates to modify the stock system?
<mjg>
do*
<sortie>
mjg: Yeah it's an old tech solution lol. I don't have those advanced filesystem features yet -- and it might constraint what filesystems I support for the root filesystdem down the load.
<mjg>
so i think you can emulate that sufficiently enough?
<heat_>
i _think_ xfs has cow but does not have snapshots
<mjg>
suppose you have one partition for the system
<mjg>
you can start with a top level dir which indicates the version
<sortie>
But it actually has a lot of safety properties in ensuring the ABIs do not mix, and the whole sysmerge --booting is idempotent, so if it fails, you reboot and try again, and it might succeed this time
<mjg>
when you boot you chroot into that as /
<mjg>
meanwhile you mount the real root device under - say - /sysupdates and populate /sysupdates/blahblah-update-with-timestamp
<mjg>
and reboot itno that
<sortie>
My sysupgrade .iso method works by having the live environment mount the existing installation, so it is / onto /mnt which is way safer.
<mjg>
you can hardlink files which don't hange
<mjg>
anyhow the end result is that you have the system intact
<mjg>
without real snapshot support
<mjg>
maybe there are some corner cases i don't see, but defo this is what i would be pursuing
<mjg>
if i could not use a fs with snapshots
<mjg>
heat_: i don't know what fs makes sense
<sortie>
I love all your ideas. The big difference is that I'm already doing this, today, and I have been doing it for years.
<mjg>
if zfs was integrated into master i would use that
<mjg>
sortie: very corporate of you
<mjg>
"wow great feedback everyone, thanks all for the productive meeting" aka "lol fuck you"
<sortie>
I built something simple and powerful enough that I can improve down the road. And I totally am, piece by piece :)
<mjg>
mate, it's your os, you do you
<sortie>
Just trying to say that my whole thing is to carefully skip out on some super advanced features and stick with basics and get the job done rather than spending even more years doing the impossible decade long release cycle :)
<mjg>
my $0,03 is ranted up
<sortie>
mjg: I do rather like what you're saying and it is the road I want to follow in the subsequent releases :)
<sortie>
One big problem with /sysupdates as you pointed out is that the system partition needs to be basically read only and not contain sysadmin files
<sortie>
Which is totally cool and a very android way of doing it
<mjg>
8(
<sortie>
I would tend to prefer some sort of transactional filesystem thing. Basically atomically make a bunch of renames happen
<mjg>
you know, back in high school in a math class i was asked to come to the writing board solve a problem from the polish SAT-equivalent
<mjg>
it was turbo trivial, sorted out in < 1 minute
<mjg>
teacher response: "precisely like in the answer sheet"
<mjg>
this is where i felt a slap in the face
<mjg>
and now this comparison to android
<mjg>
:X
<nikolar>
lel
X-Scale has joined #osdev
<sortie>
mjg, haha honestly did not mean anything by it, just point out that what you suggest is a real world thing and yeah I could do it too
<mjg>
well i don't know what android is doing
<mjg>
the above seems like a pretty obvious approach
<mjg>
so i'm not shocked if that's what they ended up with
<sortie>
#osdev is all about inventing stuff we need and realizing we just came up with something ourselves that have been done before
<sortie>
Though it would doing a whole read-only partition for the system image only which is a bit difficult
<sham1>
It's always nice to be able to reinvent some piece of tech
<mjg>
dude multicore programming circa 2015 or so is only coming up with ideas someone else already implemented
<sortie>
Considering how Unix likes to mix the system image with the sysadmin stuff
<mjg>
i'm kind of used to it
<mjg>
:d
<mjg>
interestingly some of the ideas, at least as far as papers go, date back to the 80s
<mjg>
pretty crazy
<nikolar>
yeah
Stellacy has joined #osdev
<sortie>
Yeah it's all about the execution. How well can one implement the ideas and attain desirable qualities.
<mjg>
os x demonstrates one can do an utterly shite job and still be in the market
<mjg>
8)
<nikolar>
also for at least some things, hardware was too constrained in the 80s
<sortie>
That's what I love about osdev. I get to think carefully and wee what I can accomplish that is good quality.
<nikolar>
mjg: kek apple is a special case
<mjg>
nikolar: have you heard about the 9x series of windows
<mjg>
> Portugal is EASTERN EUROPE 🇵🇹 (100% Proof)
<mjg>
:d
<sham1>
Roman is such a jem
<sham1>
gem
<heat_>
mjg, re: multicore programming have you consiered just using big locks?
<heat_>
it's a good idea
<heat_>
we might be able to radically simplify the linux kernel that way
<mjg>
heat_: i'm jusing a single core box
<mjg>
problem avoided
<nikolar>
nice
<heat_>
if you for some weird reason have a multicore processor, just use many VMs
<heat_>
mjg, you should maybe unironically try btrfs
<heat_>
i've heard it's Not That Bad
<mjg>
i had a quick look and it has extensive poorformance characteristics
<heat_>
zfs has a bunch of issues on arch because of the constant kernel updates, might be easier on ubuntu. ofc not if you're doing your own kernel builds and tinkering with shit
<heat_>
i mean it's a btree fs lol what are you expecting?
<sham1>
btrfs is *fine*
<sham1>
It's not the fastest filesystem, certainly, but it has many nice features
<mjg>
i expect certain issues which don't need to be there
<mjg>
are not there
<heat_>
if you need the OPTIMALEST code xfs (or, to a slightly lesser extent, ext4) is probably the filesystem for you
<nikolar>
btrfs isn't in a state i'd recommend it to anyone
<sham1>
Of course, if speed is the thing, yeah xfs is king
<mjg>
why
<nikolar>
literally the first time i tried it, it got corrupted
<mjg>
when was that
<nikolar>
like a year or two ago
<mjg>
btrfs was a meme 10+ years ago
<mjg>
well people insist it works now
<nikolar>
and it still is
<sham1>
Sounds like a skill issue. I've been using btrfs for years now, and never had corruption
<sham1>
Then again, I don't do RAID6
<mjg>
have you checked for corruption
<nikolar>
this wasn't raid
<nikolar>
mjg: the filesystem shat itself
<mjg>
look mofo, i believe you
<mjg>
just sayin other people insist it is stable
<mjg>
for like at least 3 year snow
<heat_>
hasn't it been the default for fedora for some time?
<heat_>
re Ermine
<nikolar>
it has
<nikolar>
my brother uses it
<mjg>
btrfs in fedora?
<mjg>
wut
<nikolar>
yes
<mjg>
how tf did that happen
<heat_>
its the future of filesystems
<nikolar>
btrfs in particular is not
<mjg>
red hat employs a bunch of ext4 and xfs developers
<heat_>
can't wait for it to be RIIR
<mjg>
perhaps they got someone for btrfs now?
<mjg>
i'm out of the game
<nikolar>
mjg: fedora loves to be on the bleeding edge (ie not working) side of things
<heat_>
says the artix user?
<mjg>
sure, but presumably they would also have people to faclitate the non-working state
<nikolar>
yes
<mjg>
in this case some btfs devs
<nikolar>
i don't know about tha
<mjg>
i thought these dudes are at suse(?)
<heat_>
the btrfs guy is at facebook
<sham1>
Did you mean: Meta
<mjg>
that too, i'm talking suse vs red hat
<mjg>
i only see suse names
<heat_>
fwiw is fedora even a red hat product?
<mjg>
yes?
<heat_>
i don't think they explicitly care
<nikolar>
yes
<mjg>
there are suck^Wvolunteers
<heat_>
most of the Real Support People are on RHEL
<mjg>
but plenty of that shite is people paid by red hat to do things wrong
<mjg>
and how do you think rhel comes to be mofo
<nikolar>
lol
<heat_>
correct, but RHEL is also a different thing
<mjg>
anyhow i only see suse.com
<mjg>
in fs/btrfs
<mjg>
no red hats
<mjg>
so wtf
<nikolar>
indeed
<heat_>
they also don't commit to ext4
<heat_>
sooooo
<mjg>
what
<nikolar>
also fedora switched to wayland by default way earlier than anyone else
<nikolar>
when it was much more shit than now
<heat_>
RH doesn't work on ext4 either mon, at least i can't come up with anyone
<mjg>
Author: Eric Sandeen <sandeen@redhat.com>
<mjg>
ext4: Convert to new uid/gid option parsing helpers
<mjg>
Author: Brian Foster <bfoster@redhat.com>
<mjg>
ext4: fix racy may inline data check in dio write
<nikolar>
lol
<heat_>
sandeen is on xfs
<mjg>
i know the guy, here he is changing ext4
<nikolar>
you know one person can do more than one thing, right
<mjg>
Author: Brian Foster <bfoster@redhat.com>
<mjg>
ext4: allow concurrent unaligned dio overwrites
<mjg>
Author: David Howells <dhowells@redhat.com>
<mjg>
ext4: Provide a splice-read wrapper
<mjg>
etc.
<heat_>
howells is on netfs stuff
<mjg>
howells is an all around fs guy
<mjg>
bottom line is they do change ext4
<heat_>
well yes that's how things go in linux
<heat_>
you change core fs code, you fix everything else
<mjg>
these were changes made specifically to ext4
<mjg>
i deliberately excluded tree-wide changes
<nikolar>
> you know one person can do more than one thing, right
<mjg>
i see only one btrfs-specific commit by red hat during last 2 years
<sham1>
Fedora is mostly run by volunteers, with Red Hat sponsoring stuff and paying some developers since they use it as upstream for RHEL
<sham1>
So yeah, the volunteers are the suckers
* sham1
is also the sucker
<mjg>
arguably it may make it easier to land a job at red hat
<mjg>
except 1. you should not want one 2. criteria to get hired are having a pulse, so...
<nikolar>
unlike at canonical where criteria are quite ridiculous lol
<mjg>
:d
<heat_>
mjg, mon all i'm saying is that ext4 code is mostly driven by huawei people, some ibm people and ted tso
<heat_>
and jan kara
<heat_>
red hat barely touches it and so does canonical or whatever
<mjg>
that may be true
<mjg>
anyhow i'm saying btrfs does not have active red hat devs
<mjg>
which makes it a bizzare choice for a default for fedora
<mjg>
given the corporate oversight
<heat_>
zfs has a lot of activity on RH's side because it's actually business critical for RHEL
<mjg>
?
<heat_>
uh, xfs i mean
<mjg>
:d
<mjg>
ye that i know
<mjg>
and i would have no comments if fedora was on xfs
<mjg>
specifically because of 2 maintainers working there
<mjg>
(dchinner and esandeen)
<heat_>
fwiw i don't know xfs is not an option
<heat_>
why xfs*
<heat_>
maybe it's not really well suited to desktop systems? *shrug*
<nikolar>
there is probably an explanation somewhere
<nikolar>
and it's probably silly
<mjg>
do we have any suckers on fedora here though?
<heat_>
i used it for a little while way back in fedora 27
<Ermine>
I don't run fedora anymore, can't say for sure, but maybe installer offers btrfs by default
<Ermine>
opensuse uses btrfs by default, that's for sure
<heat_>
dude funny story: i tried oracle linux on one of their free 1G ram x86 offerings
<heat_>
tried to dnf install a package. it OOM'd
<nikolar>
lol
<Ermine>
With 1G ram? That's lul
<mjg>
do you ever run out of funny stories heat
<Ermine>
do they use dnf4 or dnf5 ?
<Ermine>
Also, INSTALL ALPINE LINUX
<mjg>
this is nixos channel now
<heat_>
i do indeed run out of funny stories but then quickly switch to telling yours
<mjg>
smart
<heat_>
people never notice, although they do find it weird when i mention poland
<nikolar>
smartctl
<mjg>
heat_: just say "eastern europe"
<heat_>
portugal cyka blyat
<nikolar>
heat_: we already established that portugal is in eastern europe
<mjg>
that's where you are from as well
<zid>
nikolar: I've decided to switch C preprocessor
<mjg>
does this mean i should be dunking more or less on you though
<mjg>
:thinkingface:
<zid>
gcc's one is no good, I'm going to use a different one
<nikolar>
zid: which one
<Ermine>
k4
<Ermine>
m4
<zid>
phfound one on php.net
<nikolar>
now that i think about it, i am surprised that there are no popular precproessors that implement the standard stuff but also add their own things
<heat_>
gcc?
<zid>
php has really good stuff
<nikolar>
heat_: gcc doens't do anything too drastic
<zid>
<?=$meow ?> and stuff to dump a string from a database or whatever you like
<zid>
pretty gud
<zid>
who needs Xmacros when you can just do a for loop to grab it frm a sqlite
<Ermine>
this is webdev channel now
<heat_>
yes but mjg still hasn't taken my dcache_lock suggestion :(
<heat_>
note: you're supposed to use a rw_semaphore to provide unfairness
<heat_>
unfair by design = READERS NEVA STOP BABY LETS GO
<mjg>
freebsd 8 or maybe 9 is up your valley
<mjg>
with the global namecache lock
<mjg>
i regrettably removed it
<heat_>
i was checking some days ago and i think the linux dcache_lock existed up to one of the last 2.6 releases
<mjg>
when did rcu lookup show up tho
<mjg>
note the real perf killer is locked lookups
<heat_>
"Nick Piggin's dcache scalability work looks like it may be set to be merged for 2.6.38"
<mjg>
lol
<mjg>
aight
<heat_>
i dont know if you're aware but nick piggin on linux was you on freebsd
<heat_>
dude touched everything scalability wise
<mjg>
i heard of the guy
<mjg>
i just don't remember the timeframes
<mjg>
he even had a talk how scaling dcache is difficult
<heat_>
true that
<zid>
with a name like nick piggin, he probably had some childhood trauma and is trying to usher in skynet as fast as possible
Gordinator has joined #osdev
<heat_>
only satan would devise a weird graph where you need to traverse up and down and you can atomically rearrange the tree
<zid>
I think nikolar's ABV is too low, we should toss him back into the cask with some sugar
<nikolar>
:|
<zid>
what, did you want something better?
flom84 has joined #osdev
X-Scale has joined #osdev
X-Scale3 has joined #osdev
X-Scale has quit [Ping timeout: 256 seconds]
Gordinator has quit [Ping timeout: 244 seconds]
X-Scale has joined #osdev
X-Scale83 has joined #osdev
X-Scale3 has quit [Ping timeout: 256 seconds]
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale83 has quit [Ping timeout: 256 seconds]
X-Scale has joined #osdev
Matt|home has joined #osdev
X-Scale74 has joined #osdev
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale74 has quit [Ping timeout: 256 seconds]
<heat_>
mjg, what do you know about whacking dentries and inodes?
<heat_>
the linux shrinker code looks somewhat like adhoc garbage
<heat_>
i was thinking about making my shrinkers deal only with bytes, but this seems too simplistic, at least when it comes to pulling off the right proportion between whacking the inode cache and dcache
X-Scale has joined #osdev
<nikolar>
what is the shrinker supposed to do
<heat_>
shrink caches
<nikolar>
ah
<heat_>
if i strictly think about byte counts, doing a 50/50 split will naturally need to remove way more dentries than inodes, because dentries themselves are way smaller than an inode and its associated state (page cache)
<heat_>
and this _seems_ wrong
<heat_>
only exposing object counts is also wrong because then the shrinker caller doesn't really know how much reclaimable memory the cache is holding...
<heat_>
it's... weird
<mjg>
i don't know of anyone having high quality memory reclaim
<mjg>
also note how freeing this shite might not even free any pages
<mjg>
making your alloc still not satsifiable
<heat_>
i know
<heat_>
it's annoying. i think traditional slab suffers hard from it
<heat_>
SLUB does seem to favour compactness a lot, but i honestly dont have numbers on it
X-Scale has quit [Ping timeout: 256 seconds]
<mjg>
note however you can start with reclaiming memor yto replace suckers of the same type with another instances of the same type
<mjg>
which is what you need if you mean the fstree thing
<heat_>
yes, i guess that case would automagically Just Work because my pagedaemon just runs in the background
<heat_>
doing direct reclaim would be weird however, the page allocator doesn't know what slab cache it's allocating for
<mjg>
that much you can know tho
<mjg>
for cases like dentries, inodes and other suckers which hang out in a cached manner
<mjg>
it very much sounds like knowing for a fact you can reclaim one would be pretty useful
<mjg>
this does not mean you get away without reclaimingo ther cachen in general, but it is a huge leap forward
<mjg>
fwiw this replacement of one sucker with another does work great even on solaris
<mjg>
for inodes anyway
<mjg>
the fucken bsd land has a stop gap which is partially good: you can whack a vnode to replace it with another one
<mjg>
explicitly
<mjg>
the loller stems from this being the only way to do anything
<heat_>
huh linux does not reclaim inodes with pages in the page cache, for !HIGHMEM
<heat_>
i dont know what the end result is here, but it sounds a little troubling
<mjg>
i don't know what they do
<mjg>
freebsd tries hardcore to not reclaim stuff with any data hanging
<mjg>
there is probably wrong heuristics how to do it, all defecated in the 90s
<mjg>
they also fundamentally don't even work for zfs....
<mjg>
:d
<mjg>
(as in for zfs the code is not even doing what it claims)
<nikolar>
doesn't zfs have its own layer for that stuff
<mjg>
yes and no
<mjg>
it's poorly integrated and you get OOMed when there is plenty of whackable arc
sbalmos2 has joined #osdev
<mjg>
aight mofos, you are all pieces of shit and i'm bailin
<mjg>
cheers
<nikolar>
oi
andreas808 has quit [*.net *.split]
chibill has quit [*.net *.split]
SophiaNya has quit [*.net *.split]
ptrc has quit [*.net *.split]
gorgonical has quit [*.net *.split]
sbalmos has quit [*.net *.split]
jimbzy has quit [*.net *.split]
jistr has quit [*.net *.split]
isabella has quit [*.net *.split]
phr3ak has quit [*.net *.split]
kline has quit [*.net *.split]
pax_73 has quit [*.net *.split]
LittleFox has quit [*.net *.split]
basil has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
dennisschagt has quit [*.net *.split]
urandom__ is now known as urandom
urandom is now known as 003AAA1NQ
valerius_ is now known as valerius
valerius is now known as 073AABUUJ
LittleFox has joined #osdev
SophiaNya has joined #osdev
isabella has joined #osdev
jistr has joined #osdev
phr3ak has joined #osdev
kline has joined #osdev
pax_73 has joined #osdev
basil has joined #osdev
SanchayanMaity has joined #osdev
dennisschagt has joined #osdev
andreas808 has joined #osdev
ptrc has joined #osdev
chibill has joined #osdev
andreas808 has quit [Max SendQ exceeded]
andreas303 has joined #osdev
X-Scale has joined #osdev
<heat_>
oh linux ARC reclaim is just a single shrinker
<heat_>
this tbqh sounds terrible
pax_73 has quit [Ping timeout: 265 seconds]
pax_73 has joined #osdev
<sortie>
heat_: (Beself) I like how I really actually know none of those technical words lol
<sortie>
Like you know? I actually studied very few things that the Linux kernel do
<sortie>
I totally should.. lol
heat_ is now known as heat
<heat>
ARC is zfs's custom page cache (because of course), reclaim is reclaim, shrinker is basically a fancy object with function pointers that shrinks a specific cache
<heat>
dentry is an element in the directory cache, inode is inode
<heat>
HTH
<sortie>
reclaim is what? Taking back a physical frame by swapping it out or discarding or such?
<heat>
yes
X-Scale has quit [Ping timeout: 256 seconds]
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
m3a has quit [Ping timeout: 255 seconds]
<Ermine>
wut, ARC is rust async garbage collector
<nikolar>
lol async reference count, but sure
flom84 has quit [Quit: Leaving]
<nikolar>
No wait, atomic
<nikolar>
Not async
m3a has joined #osdev
Starfoxxes has joined #osdev
X-Scale has joined #osdev
heat has quit [Read error: Connection reset by peer]
Starfoxxes has quit [Read error: Connection reset by peer]
Stellacy has quit [Quit: Leaving]
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
Stellacy has joined #osdev
Stellacy has quit [Ping timeout: 260 seconds]
Stellacy has joined #osdev
Stellacy has quit [Ping timeout: 260 seconds]
Stellacy has joined #osdev
npc has quit [Remote host closed the connection]
spareproject has joined #osdev
gcoakes has quit [Ping timeout: 252 seconds]
scaleww has joined #osdev
Turn_Left has quit [Remote host closed the connection]
Turn_Left has joined #osdev
Gooberpatrol66 has quit [Read error: Connection reset by peer]
mavhq has joined #osdev
scaleww has quit [Quit: Leaving]
goliath has quit [Quit: SIGSEGV]
zetef has joined #osdev
<dostoyevsky2>
Isn't it weird that one of the lightest filesystems is called fat?
<netbsduser>
aarch64 has defeated me
<nikolar>
how
<netbsduser>
i have ported my kernel to it but i have not been able to solve a big problem
<netbsduser>
namely synchronous exceptions with esr=0x2000000 in userland demand-paged code
<nikolar>
huh
<netbsduser>
despite cache maintenance code in what appears to be all the right places
<heat>
real hardware?
<netbsduser>
qemu with kvm on a pi 4
<netbsduser>
in qemu non-kvm no problems
<netbsduser>
i cleared up most of the instances of this problem when i first added cache maintenace logic around page in
<netbsduser>
as far as i can see the problem seems to be suppressed if i disable the local level of page replacement. but that shouldn't be a problem as i am not recycling inactive pages, so the pages containing executable data are not replaced
<netbsduser>
even littering ic iallu everywhere is no help
<heat>
"but that shouldn't be a problem as i am not recycling inactive pages" huh? what are you recycling then?
<netbsduser>
nothing
<netbsduser>
the global level of page replacement is not operating whatsoever here
<heat>
are you sure?
<netbsduser>
completely
<netbsduser>
i turned it off
<heat>
what's the "local level of page replacement" then?
<netbsduser>
the limitation of the number of pages that a process' resident set can prevent the global level of replacement from evicting
<netbsduser>
i keep that limited to 512 right now to keep the code paths exercised regularly
<heat>
funkay
<netbsduser>
when there's more than 512 pages in a process' resident set, the global reference on one of them is released and the PTE becomes invalid
<netbsduser>
since there is no re-pagein there should be no opportunity for staleness of instruction cache
<netbsduser>
as when that page is faulted on again it's brought back in
<netbsduser>
the same physical page
<heat>
hmmm... are you sure you don't need to maintain the icache in those cases too?
<netbsduser>
i've tried anyway to no avail
zetef has joined #osdev
zetef has quit [Client Quit]
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
eddof13 has joined #osdev
netbsduser has quit [Ping timeout: 244 seconds]
<heat>
i have umount baby lets go siuuuuuuu
<heat>
the haters said i couldn't do it
<Matt|home>
hello..
<nikolar>
ello
gcoakes has joined #osdev
eddof13 has quit [Quit: eddof13]
spareproject has quit [Remote host closed the connection]