foreign
[Music]
hi everyone welcome back from morning
tea hope you had a good one
um we have an interesting talk uh up
this morning uh so what has RCU done
lately
um and this will be from Paul McKinney
he is a kernel hacker working on various
parts of the read copy update
implementation in the Linux kernel along
with his team uh today's talk will be
covering all of the recent work in this
implementation as well as RCU work going
on outside the kernel uh so please give
Paul a warm welcome
[Applause]
thank you Sam
so this is the team uh Buchan was in a
reflective mood when he took the picture
so but there there we are
uh one thing that uh sometimes I get
questions about is whether RC really is
still changing I remember a poor guy was
uh very surprised by this uh I didn't
have the heart to tell him that not only
is RCU under active development but spin
locks and atomic operations are also
interactive development
so first we're going to do an RC review
and this is going to be quick there are
some URLs at the bottom of the slide
here and those will be available to
people that give you a much longer and
gentler introduction to this but uh
we're we're just going through it for as
a reminder so the purpose of RSU in
short is to work around the laws of
physics
now when I was a kid I was well aware
that the finite speed of light was a
problem for things like say Interstellar
travel
but I would have been quite surprised to
find that that finite speed of light and
the non-zero side atoms was going to be
a problem for computation but here we
are today
this kind of gives a quick overview of
what RCU does at a high level
what we have is time going from top to
bottom and it's really ordering but
let's call it time anyway in each of
four scenarios the scenario in the upper
left we reader they start with RC Reed
lock they end with RC read unlock and it
started before
an object was removed there
and that means that this reader might
have a reference to that object
and that in turn means that the reader
had better be done before we free that
memory I mean use after freeze are just
as bad with RCU as they are every
anywhere else please don't do that right
and rsu's purpose is to prevent that use
after free and in this case the
synchronized RSU would wait until all
the pre-existing readers got done before
it returned thus preventing that use
after free
in the upper right we have it the other
way around we have a reader that stayed
around and was still in force after the
free and therefore it better be the case
that that reader started after the
removal so that that freeing can't
inconvenience it it can't possibly have
a reference to the thing that was
removed so it's okay still
we can have the belt and suspender
scenario which is in the lower left
there not only were we not around when
we got to bring the object but we also
weren't there to see it in the first
place
the bad scenario the lower right is a
bug in RCU here we have a reader that
was there before the removal and was
still after the free that'll be used
after free potentially and again that's
a bug in RCU what should have happened
is it synchronized RCU should not have
returned so said
so that's kind of a quick view of the
base semantics
this is code that relies on it and what
we're doing here is we're combining
temporal synchronization again really
ordering on the y-axis going down and we
also have address space synchronization
going from left to right
so we have this Kirk config variable
it's a pointer initially it pointed to
that blue object and so we have a reader
on the on the left that started early we
have a reader on the right that started
late the reader on the left started
early so it gets the old object the blue
structure 3746 because it is appointed
to that it'll still use those consistent
pair of values and not be confused by
the later update
again the reader came first synchronized
RSU has to wait for it so the free can't
happen until that reader gets done
the other reader came later therefore it
doesn't get a reference the old object
instead it gets the new object and again
it gets a consistent set of values so
what happens in some sense we have a
kind of a zone of confusion between
those two dotted horizontal blue lines
and the confusion is resolved by the
change in address space between the blue
and the green structure
now it may seem kind of crazy that you'd
have a reader that might be using stuff
after it was obsolete but keep in mind
that most of our computers are
interfacing to the real world and so is
that red dotted line up there earlier
that's when the change happened in the
real world and so we could be totally
consistent in the computer but we'd
still be out of sync with the real world
RC was just admitting that we do have
that lack of synchronization
all right we talked about time and space
we've seen the first three of those and
they the limit time for us or ordering
if you prefer call RCU is like
synchronize RSU except asynchronous you
give it a function and it calls it later
and the bottom three
um uh the top uh the first two rcd
reference in France load pointers and
the rco sign pointer updates it we used
an atomic Exchange in the example just
to make it fit on one slide
all right and this is what we're doing
here if you had reader writer locking
that works great by the way but uh
because you have this in classic reader
writer locking you have the same lock
object and that has to be atomically
manipulated that's going to mean delays
as it gets batted around along the CPUs
and those delays are represented by
those red that red in that
we have latencies to get the global
agreement we need to switch from readers
to updators and back
in contrast with RCU we don't have that
lens see there's no not it's not
necessary to have a single Global shared
object and so we can get much more
efficient use of the CPU
okay well it's easy to say that you
might want some evidence here's a one
straightforward thing this is a crude
Benchmark where we use an empty Reach
Out critical section so we acquire read
acquire lock we immediately release it
we do RC read lock and we immediately do
our secret unlock as you can see the
reader writer lock even though not much
is happening otherwise on 200 CPUs is
chewing up better part of 10
microseconds just to acquire the lock
and to release it nothing else happening
RCU on the other hand is flat all the
way out to 200 CPUs and we've measured
in Labs we haven't published it we
majored in Labs out to a thousand you
see that Jitter down there around send
CPUs is most prominent that's due to
hyper threading the thing is that one of
these RCU
threads can use up more than half of a
core so if you have two of them the same
core they fight a little bit and get a
little bit lower throughput
and we don't control which thread runs
on which CPU so we see that Jitter in
the middle there
of course an empty reset critical
section is kind of useless not entirely
useless but not what you normally want
so if we add something in the critical
sections and you can see the latency the
duration of that critical section on the
bottom ranging from 100 nanoseconds to
10 microseconds
and we still have the nanoseconds for
operation on the y-axis what you can see
from this is that the performance
disadvantage of reader writer locking
decreases as you increase the critical
second duration as you'd expect the
overhead drops down into the noise
however it also decreases with
decreasing numbers of CPUs in short if
you have really big critical sections
they have almost no CPUs redu Rider
locking will do just fine for you on the
other hand if you have lots of CPUs and
very short critical sections like you're
protecting a very fast data structure
like hash table RCU has great benefits
early on
all right there's also restrictions rco
is a specialized tool it works best when
you mostly have readers over there on
the right and staling consistent data is
okay now you can restore consistency if
you want there's patterns that do that
and it's also there are also a couple of
use cases when you're all updating and
you need consistent data but they're
more rare
uh the most common uses are up over
towards the blue section
and the other piece is that RCU is most
frequently used for blank data
structures there are some non-link data
structure use cases but they're rare
and the use cases are here the this is
the same two URLs we saw earlier and
they go through this in detail what we
saw in that little code example was the
upper left there the quasi-reader rider
lock and the most of the complexity in
RCU it's quite simple just in and of
itself you wait for all pre-existing
readers what can be simpler the
complexity is making it work with the
use case and fitting in with everything
else that's where a lot of the
complexity is
okay so we blasted through a review uh
and again if this is your first exposure
to RSU please take a look at some of the
other material including those two URLs
but we're going to go ahead and look at
some changes that have happened more
recently and this is just a quick list
of the ones we're going to go into a
little bit of detail on but again this
is going to be a bit of a flyover each
of these topics most of them could be a
full presentation we're going to give
you a taste of what's happened as
opposed to trying to dive deep in any
one of them
all right
flavor consolidation is a follow-up I
actually presented this at Linux Au in
2019 so it'll be even flying faster I
got a email from elinis Torvalds that CC
security at kernel.org and didn't see CL
came out which is usually a hint that uh
you're not going to be minding your own
business for a little while
uh there was an exploit uh this don't do
this uh what don't you do and and Lena
said look can we have some way of making
this mistake harder to make or
impossible to make and the problem was
we had different types of readers
and you had to make sure you got the
readers paired up with the proper
updater if you did one reader and the
other updater like happened in the
exploit uh then uh you could have all
sorts of problems like Linux security
holes as what as what actually happened
so I had a simple conceptually a simple
fix which was to say okay synchronized
RCU is going to match up with everything
we're not going to have different kinds
of updates use synchronize RC and that
will take care of you and that that's
nice and simple other than it took me a
good year to actually make that
transition uh but one thing is not
simple is if you need to back port a
patch from say 6.2 to 4.16. the 4.19
uh that's a bit of a gap there
okay so if it's 4.20 or later that
you're backwarding to no problem it just
works but if it's four times earlier you
have to take a look at what your patch
is because the semantics changed now if
your readers are only RC read lock then
you're golden just take it back it'll be
fine otherwise there's a synchronized
RCU mold that causes
multiple weights concurrently uh as
shown in that little example there and
you can chain call RCU the different
call rcus together one after another by
having the one back invoke the other the
next uh call RCU variant and get that to
work
okay so it's something that can be
handled but be careful if you fail to do
this if you just backboard it and you
should have made a change the bugs are
really difficult to reproduce and
difficult to find
okay so with that guy taken care of what
I learned out of this is a key security
property is ease of use
my code was in some sense correct or
close to it but
um it didn't interact very well with the
people so that I had to fix
uh Joel Fernandez starting five four
made some mods to list for each entry
RCU and ageless differentiate RCU the
old style which is still supported uh
what happens is you Loop through it's
like list free Gentry you Loop through a
RCU protected list and what it does if
you have locked up enable it says Hey
there'd better be an archery Block in
effect otherwise this is this isn't safe
and I'm going to complain
and that's okay except that sometimes
you'll have shared code that is also
called for an update side so it might be
it's okay to be an RC reader or it's
okay to hold event mutex
and so what Joel did was he added a
locked up an optional uh locked up
expression to these guys shown on the
bottom there
and what you can do is put something
like lock type is held Ampersand event
mutex in that optional position and
that'll tell lockdep okay we either have
to be an RC reader or we have to hold
this lock either way is fine and so
you're exposing more of your a design to
locked up and it allows uh shared code
to work better
okay so this gave us debug ability
improvements without an API explosion
which is a good thing
uh vladislavresky uh in five nine gave a
single argument K free RCU
and uh what happened the old way of
doing things you have cave cafe or K3
RCU their synonyms at this point
um you gave it a pointer that's p and
you also gave it the field name of an
RCU head field in the object and that's
the RH there now the nice thing about
this it just bang it happens it never
sleeps and we'll it's continues to be
reported supported it's still useful
we'll still have it
but one problem with it in some cases if
you have a really small structure
and that structure has there's a huge
number of them in the kernel
the extra eight bytes or four bytes in a
32-bit system of that RCU head can be a
real problem
and so a new way you could do it is
leave off that second argument just say
KV free RCU of P like it shows there and
in that case you don't need that RCU
head sure in your in your object
but the trade-off is that it's going to
allocate memory to track this thing and
of course if you're out of memory it can
sleep uh so you know there's a latency
issue and also you can't use it from a
tonic contacts
all right this has been around for a
while and that was that was wonderful it
helped out some people with the memory
footprint except that it turned out to
be a use ease of use problem again
and the problem is is that it was just
really easy to just forget that field
and so instead of typing the KB free RCP
comma RH just kv3p kv-3 rcop the
compiler is fine with that didn't work
great unless you recall it from Atomic
context in which case locknip would
complain
but sometimes you're in a in an
environment that can sleep
but you don't want that extra sleep from
Caper for your RCU it might be that you
have an SLA to meet and that sleep is
going to be too much
so uh Eric dumasay ran into this found
this problem
Google's Google's Fleet and so what
happened was that we no longer allow the
single argument version of KV free RCU
instead you have to put the might sleep
suffix on it okay and uh what that means
then is that you have a bigger Hemi
distance between the correct and the
incorrect variant of it and the might
sleep the nice thing about that is you
look at this thing and it tells you
right there hey this might sleep which
is added documentation
uh while he was at it Vlad also uh used
the pulled grace period API we'll
describe next and that really seriously
reduced the memory footprint uh uh under
under a micro Benchmark but still it was
it was order magnitude style reduction
which is great
so uh what I was surprised is sometimes
the views requires more typing rather
than less but here we are
okay I said pulled grace period apis and
here they are
I'm not going to go through this in
detail I'm just noting that the first
move in this direction happened in 3.14
almost 10 years ago
and the way they're used is on this
slide so what happens is you call get
State synchronized RCU it just hands you
back a unsigned long you put it in a
cookie you go do something else and
something else might take a fair amount
of time and then you pass the cookie to
con synchronize our shoe or con
synchronizes RC under expedited if you
want to thing to go fast and what it
does is look it says hey has the grace
period corresponding this to this cookie
ended already and if it has it says okay
great I'll just return
otherwise it invokes synchronized RCU or
synchronized under RSU under a bar
accident depending on what you when you
chose at that point so if you do
something takes a while you get safety
but you don't get the extra overhead
and what you'd like uh so what I'll just
give you an example usage here before
getting the next thing
and so what we have here is we have a
state diagram we've got a single element
that's in an RC protected data structure
but it's a cash like thing where you age
things out of the cash and you age it
from left to right there one two three
four
so initially on the left we've got it
it's actually in the cache readers can
get at it and that means you have to be
careful with it so we find something
that hasn't been used for a while or
maybe it's something about it we decide
we're going to pull it out of the reader
visible section and on the way out in
state two there we note we give it a
cookie saying okay the grace period
started and then we put it going to
state three now in state three it could
be a reader says no wait a minute I want
that back and so we list add RCU it
whoops a list add RCU it back into the
reader visible chunk or we might uh note
that the readers are all done the grace
period's over in which case we can move
it to the fourth section where it can
sit for a while if need if desirable
where all the readers are done it's uh
it could be used anytime and the cool
thing about that is if you get an oom
event and out of memory of that all the
guys in state four can be immediately
freed which allows you to have the
archery readers and have it be safe and
have the delays that make it so that you
can immediately respond to this out of
memory event
until next slide we have the same thing
only we're showing The Primitives used
on those transitions from left to right
list lrc has been around for a long time
and that's what we use to remove this
element safely from the list of readers
then we use get State synchronized RSU
which we've seen before or uh start pull
synchronized RCU which uh to get State
synchronizer so just gives you a cookie
uh get start pull synchronous RCU gives
you a cookie and it makes sure that the
gray sprees you need are going to start
uh pull State synchronized RCU just
pulls the thing and says uh is it done
yet and if it is that's our y there and
we can move it over now uh we this thing
is subject to counter overflow we've
only got a limited number of bits and
they can overflow and so there's a get
completed synchronized RCU that gives us
a Cookie that is Perma expired if you
get a cookie from get completed
synchronized RCU pull State synchronized
artist who's always going to say true
yep that thing's expired
and that means you can avoid counteract
problems which aren't much of a problem
64-bit systems but there still are
32-bit systems running around
okay so uh
here's the same sort of thing again
except instead of using con synchronized
RC we're using pull State synchronized
RC and what you'd like to have happen
but which does not work you'd like to
get your cookie and then if you somehow
do a synchronized RCU you would like it
to be unconditionally the case the pull
State synchronous RCU says yeah that
grace period is done but there are two
reasons that doesn't happen one is
counterwrap which we've already
discussed the other one is that we have
both normal and synchronous and
expedited Grace periods the normal ones
are slow but use less CPU the expedited
ones are much faster but hit the CPUs a
lot harder and interrupt other CPUs and
aren't so good for real time
now
get State synchronized RCU returns a
single counter so these are mushed
together and because we had 128 bits of
State represented 64 bits we lose things
and what we lose is that if if this
synchronized RCU happens to overlap with
an expedite synchronized RC somewhere
else
one or the other of those events can be
lost and so that means we get a false
positive trigger however
if you duplicate that as RCU then you're
guaranteed that one or the other of them
will win either that or something in
between them wins either way
the cookie will notice a grace period
passing now you can still get false
positive wardons there but those will
only be due to counteract
most of the time you don't care most the
time uh wait one gracer weight grade two
Grace periods who cares but sometimes
you do care and sometimes you're willing
to pay a price of a larger data
structure and so each of these things
has an under bar full suffix
and there you're getting two counters so
you have a full representation of this
representation of the state
now
that might blow your data structure
however it turns out that there's only a
few values of each cookie that can
possibly correspond to a grace period
not yet being done
and those two uh CPP macros and I'm
active CPU macros tell you in each case
not full and full how many of those
there can be and so you can have an
array of that size and then know that
you can only have that many that are
waiting still and so instead of having
the cookie in each element of your data
structure you can put in that very small
array size
so using the full same sort of away here
because we have a structure we pass it
by reference to get State synchronized
RCU full in this case we only need one
grace period and full State synchronize
our shoe full can trigger but again only
to counterwrap and we got two counters
and they both have to wrap just the
wrong way so you have to work to make
this happen
especially on a 64-bit system
so what this means is we have a lockless
grace period API if you really want to
you can interact with RCU Grace periods
from an nmi Handler
which seems kind of unusual we really do
have people wanting this and using this
for example from Atomic context or
Hardware interrupt handlers
okay
I'm not I'm going to go through these
really quickly mostly these are things
used for uh for tracing free trampolines
especially
and these guys are all very specialized
uh here they are the main thing I'm
going to do is and by the way
implementing these and getting them
working and speeding them up as I was
greatly assisted by a neurology
and the key thing is these are for
tracing a BPF if you really need them
okay fine but talk to us talk to the
tracing folk talk to the BPF folk
because it's really easy to abuse them
in a way that messes it up for them all
right so if you need these make sure you
let us know
all right uh this next topic is callback
offloading and de-off loading this is
something contributed by Frederick
weisbecker it's available in V 5.12 now
first off what the heck's offloading or
de-off loading and why do you care
this is the classic way that callbacks
are invoked so what happens remember we
have readers and we have Grace periods
and what happens with call RCU is that
you have a function that's invoked and
these are kept active with a list of
little RCU head structures and then once
the grace period has ended we grab that
RCU head and we call the function of
half of the argument that's in that RC
head structure
and those callbacks by default today and
it used to be the only way you could do
it
are invoked in soft irq environment all
right so cpu0 does a call RCU that
enqueue something sometime later uh
software queue happens and we freeze
some memory usually and life is good
except that this thing is invoked in
there a priority and it's likely
disrupting whatever's intended to
execute about this time I mean it
doesn't matter you might have been
running a 99 prior real-time sched 50
task the highest priority you get as a
user it'll still interrupt you okay and
the the real-time guys don't like that
for good for good reason all right
so what we did and this is something
that Jim Houston and Joel Cordy uh uh
spearheaded uh back in a special purpose
real-time Linux back in the day
but what we do is instead of having the
CPU do it we offload these things so uh
if CPU
CPU one there does a call RCU there's a
grace period but instead of invoking it
at software queue on that CPU it instead
gets invoked on an on a cape a separate
thread that's associated with that CPU
but does not necessarily run on it it's
going to run wherever the scheduler
sells it to or you can manually place it
somewhere if you want to
but even if it does around CPU one it is
running as a normal task and that means
it won't preempt high priority tasks so
this works better for real time even if
it is running on the same CPU
all right so we have two ways you can
run callbacks they can be not offloaded
uh and run in software to context which
is a little bit more efficient or you
can offload them and have better real
time and HPC properties
problem is and this is great it reduces
Jitter and saves power the safe power
was a surprise but a very nice one
except that you have to choose a boot
time which CPUs are offloaded back in
the day this wasn't a problem but we
have lots and lots of Hardware threads
and lots of cores and having that baked
in for all of runtime is becoming
inconvenient and so what happens is that
Frederick made it so that there's some
new internal apis SAR so and OCB
uh CPU offload and RC and OCB CPU d-off
load on the bottom there and what those
do is you can tell one CPU to switch
between those two modes at runtime and
you have to have a particular your
kernel has to be set up properly for
this by default this you won't get this
but then you won't get offloading in the
first place all right now
um you're growing well I'm a system
administrator or I'm a user of why do I
have to write kernel code to change this
and that's the current state this is a
first step towards runtime adjustment of
the no hurts full which is the
essentially Hardware response you know
uh bare metal response from a given CPU
and that once we get that all the way
done this is just one step in a very
large puzzle for this then there will
clearly be user Space controls
up to that point if somebody needs it
let us know but we don't know of a use
case for just the Callback offloading
okay so that's some great work from
Frederick uh one of the things is
putting RCU on a memory diet
back before
v4.12 the SRC struct was a small thing
but the problem was that there was a
single callback list and that meant that
there was Global contention on this
thing
and we were having more and more use of
srcu and thus more potential for there
being lots of call ourselor fuse or lots
of synchronizers to use concurrently and
that would cause law contention
so in 4.12 we added the SRC you know
combining tree and that's just a way of
causing small groups of CPUs to contend
the winner of that contends and so on up
the tree
so you can have a huge number of CPUs
and keep the lock contention
fixed and bounded
problem is that this was allocated to
build time and the only thing we had was
in our CPUs and in some distros this
thing can range up to 4096.
um and that can be a pro and it's not
that much of a problem if you get that
big of a machine it's only 26k
but uh the thing is people put srcu
structs inside of other structures and
so they have a fast path that wants
something underneath
the srsu is struck and suddenly they
can't use the short assembly immediate
offsets and the compiler generates worse
code for them on their fast path and
that wasn't considered a friendly Act
so in V 5.17 what we did was we made it
so that the srcu node combining tree is
allocated separately and it's optional
all right
and because it's allocated separately at
runtime instead of having used the big
NR CPUs huge thing we can use nrcpu IDs
which is set to the biggest number of
CPUs this particular system booting
right now could possibly have which is
usually way way smaller than 4096. so
even if you do have to allocate the
combining tree it's smaller and in most
cases you don't need it all right and so
in a lot of cases you can just have the
SRC instruct another little pointer
so uh how do you make this work well by
default what happens that the default
boot parameters are on the bottom there
if you have less than 128 CPUs you just
have this srcu struct with a null
pointer and that's all you have
if you have a big system then contention
is more of a problem and so what we do
is uh when we when you allocate the
structure when you initialize the
structure it unconditionally allocates
the array but again it's smaller it's
just the NR CPU IDs
okay that's the default approach there
are other approaches you can set the
instead of setting the
uh convert to Big to three you can set
it to zero in that case it says just
never allocated which might be a good
choice if on a small system
and the other thing you can do is you
can you can say uh
convert to big as one in which case
it'll always allocate it no matter how
big your system is and if you have a
situation where you have a kernel module
that's just hammering SRC updates
heavily you might do that just to get it
out of the way and there's another one
on the bottom for Pursuit torture the
other thing you do are just showing the
lower bit of this thing you can use the
lower nibble excuse me if you use the
next nibble up
uh that says do conversion on contention
and that seems like a lot nicer right
because you just let it be there and if
you have contention you increase it
um like this okay
and if you do that then it would just
leave it alone if you have contention it
would allocate it up uh the problem with
this
is that uh we haven't yet learned our
trust this is a large increase in state
space there's a lot of things that go
wrong we need a lot of experience on it
before we make it be default it's there
if you want to play with it if you need
it great use it let us know how it works
and at some point we will make this
default unless something breaks but it's
not there yet and we'll also make this
the fault perhaps we can remove some of
the of the other options we'll see
uh and the overall lesson here is memory
is cheap compared to when I was uh much
younger but it's not that cheap there
are other things that uh run into there
this is just a cheat sheet for people
looking at the at the presentation even
organized view of the of the kernel boot
parameters
another thing that happened and this is
also an assist by Frederick weisbecker
is it the print K guys need an nmi-safed
srcu to have a lockless print K and so
we added the nmi safe variants of that a
key thing here is that you can't mix and
match if you have an srcu struct
and you do SRC readlock nmi safe you
have to always use the nmi safe variants
of the readers on that structure
if you ever use an sr3 to unlock without
the nmi safe you don't get to use nmi
safe on that structure ever once the
reason for that is that in theory mix
and match but it's really you have to be
really careful about it
and we also have cross CPU SRC readers
now so that you don't have to be on the
same task or CPU
okay so specialized SRC readers
um uh this is something vladretsky
contributed I'm not going to go through
that in detail but uh expedited rccp
install warnings are something that have
used to be in the 1990s and 90s PTX
quite short they're quite long in Linux
and he came up with 20 milliseconds for
expedited Grace periods and uh
collection there was a few mods needed
to make this work uh once they got those
mods done they reduced the maximum
latency on their tests of expedited
Grace periods from about two seconds to
two milliseconds that's three orders of
magnitude which is pretty freaking
impressive
so there were a few other issues that
were needed to be fixed Vlad rescue took
care of those in 6.0 and this looks like
it's working quite well and is helping a
lot with some of the uh small scale
um embedded systems
and so at last our star warnings at
least for one aspect are faster than
1990s
we're going to go through lazy RSU
callbacks fairly quickly uh these this
is a system that is mostly idle and it
wakes up and does every once in a while
so we've got the app and when it wakes
up it closes a file when it gets done
well you close the file and your
multi-threaded app the kernel has to do
a call RCU to clean up that file of
scripture safely and that means RCU
schedule is a grace period if these
things happen fairly far spaced apart
which they do if the if the thing's
almost idle you get lots of Grace
variants and that costs you lots of
battery power
and my personal preference was for the
app just to leave the file open for
crying out loud and it'll save a lot of
time and effort but uh organizational
problems apparently prevented that to
straightforward solution being
implemented so what we did instead and
this is uh Joel Fernandez with assist
from Frederick weisbecker it's a 6.2 is
that you just wait for up to 10 seconds
before you worry about the grace period
after all the call RC all it's going to
do is free some memory so you know who
cares
and that gives us a some tens of percent
in some cases a few percent or a few
tens of percent uh Improvement in
battery Lifetime on those systems so
that's pretty impressive of course uh I
would I still argue that if they fix
this in user space and didn't do the
call rcu's they'd have even more battery
saving and who knows maybe that'll
happen sometime
all right and those more details on uh
What uh how to set it up and what its
limitations are uh you guys already knew
lasers via virtue and it's yet another
piece of proof
there's a call RCU hurry you use if
laziness is not a virtue for your
particular use case that will just
always immediately start the grace
period if there isn't one already going
okay uh this is a bunch of other stuff
that's going on I'm not going to go
through it in detail but uh you can look
at it if you'd like
uh looking to the Future
uh the main thing I'm going to cover
here is the bottom this is the common
case most changes to RC were things I
would never have guessed and I don't
expect that to change
that's a long-term Trend the upper
line is RCU commits the lower line is
the ones done by not me
early on it was Deepak or Sarma doing
most of them so most of them were not me
but more lately since I took over for
real-time RCU it's been mostly me and
that's a percentage which is noisy and
is it increasing and decreasing who
knows so we smooth it out over two years
uh in April the two years ending in
April of 2017 there were 47 46
contributors and 74 of the patches came
from me popping ahead to March of this
year the two years ending march of this
year there were 67 contributors which is
good that's more and only 60 of them
were for me which kind of feels bad to
me but it's actually pretty healthy for
the community in general uh you know I I
don't bleach with my hair this is my
natural hair color
all right uh the other thing is that
software wrote in 1977 is still in use
that was more than 45 years ago it seems
like a fair bet that the Linux kernel
might be in use 45 years from now
admittedly the software wrote in 1977 is
only used in a museum but it was used
this year so you know the the danger is
real
and so therefore a first Public
Announcement Joel Fernandez and motion
Fung will be handling the RC release
into the 6-4 Verge window they've
started on that my goal is to have at
least one more group uh doing that in
2023 by the end of 2024 I'd like each of
the five to have done a release on their
own but we'll see how it goes I may have
to adjust that
and at this point I'm going to skip
ahead through the standardization and uh
right to the summary here uh we've been
through this uh the main thing is that
RCU is still under active development
driven by the needs of its users past
present and future the End Future Part
being the thing we talked about most
recently
uh okay oops I'm going backwards that's
bad this is a bunch of more information
that's slightly available we went
blasted through a bunch of stuff you can
get the full story here
and uh here we are again all six of us
and uh I'm happy to take questions
and if there are questions I can ask you
guys questions I guess
any one questions
nope
oh yep
are you talking about the srcu struct in
there and how a lot of use cases in line
that into their other structures uh how
big is that now yeah
so you said that's more I was curious
how much more
um I think it's a few hundred bytes let
me go back and not I guess it doesn't
really matter but uh
yeah okay so
there
um
but if you if you uh so the first off is
going to vary from architecture to
architecture based on the size of things
uh uh one thing would be to uh just look
at it with uh with any of the tools
looking through the dwarf information if
you have a hard time getting it uh drop
me an email and I'll mail you back uh
what the size of it is for the runs I
run on x86 64-bit
but it's but the thing is almost all of
SRC struck was that combining tree
um actually I could try some here
I'll try something stupid
um I will try to
uh let's see
try that
okay forget it I won't try something
stupid because it's not cooperating when
I'm in this mode I was going to try to
pop up an X term and look at it but I
did set up for that's no joy
but it's an excellent question again I
believe it's on the order of a few
hundred bytes it's way way smaller than
26 kilobytes
anybody else got any questions
sorry
if uh nobody has any other questions uh
we'll say thank you uh to Paul please
give him a wonderful Round of Applause
and thank you all for your time and
attention