►
From YouTube: CDS Reef: Performance Meeting
Description
The Ceph Developer Summit for Reef is a series of planning meetings around the next release and some community planning.
Schedule: https://ceph.io/en/news/blog/2022/ceph-developer-summit-reef/
A
A
There
was
one
closed
pr
this
week.
This
is
adam's
great
pr.
I've
got
the
world
on
a
string
sitting
on
a
rainbow.
I
think,
let's
see
is
adam
here.
I
don't
think
so
right
now,
so
the
the
gist
of
this
one
was
that
I
think
a
lot
of
it
got
moved
out
into
other
vr's
and
other
work
and
and
the
stuff
that
remained
wasn't
really
necessary
anymore
or
is
being
added
to
something
else.
A
If
it
is
so
that
got
closed
by
adam,
we
did
have
a
couple
that
were
updated
this
week.
Corey's
excellent
pr
has
had
a
lot
of
discussion
and
both
casey
and
igor
have
reviewed
it
and
it
it
looks
pretty
good.
The
only
comment
that
igor
had
made
was
that
maybe
we
should
have
a
configuration
parameter
to
to
switch
it
back
to
the
old
behavior.
In
case
we
caused
some
kind
of
odd
corner
case,
which
is
probably
not
a
bad
idea
it.
A
You
know
it's
a
little
crazy
to
be
option.
You
know
adding
options
to
revert
performance
improvements
or
bug
fixes.
Really
in
this
case
I
think,
but
this
one
might
be
warranted
igor.
Otherwise
did
you
did
you
feel
or
your
casey
either
of
you?
Did
you
feel
pretty
good
about
it?
I
I've
only
had
briefly
looked
over
it
and
you
know
know
the
general
idea
of
what
it
does
casey.
I
know
you
had
a
couple
of
things
you
want
to
change
earlier.
B
A
Yeah,
I
I
I
can
understand
your
your
your
concern.
There
they're
igor,
sometimes
rocks
tv
can
be
really
temperamental,
so
it's
yeah.
I
don't
think
this
should
cause
issues
just
given
what
I
I
understand
about
how
it
works,
but
but
yeah
I
I
do
get
the
the
concern
and
casey
are
you?
Are
you
satisfied
now
with
the
vr.
C
A
Yeah,
I
mean
oh
good,
corey
you're
here
you
know
what,
let's,
let's
let's
talk
about
it
more
once
we
get
through
the
prs,
because
now
we
can
have
a
bigger
discussion.
I
think
so,
let's
see
other
updated
prs
my
time
based
algorithm
for
the
allocator
for
for
for
the
adl
allocator,
so
the
big
win
was
we
already
did.
A
That
was
to
fix
the
the
repeat,
the
repeated
searches
from
the
same
cursor
position
for,
like
you,
know,
every
time
you're
doing
trying
to
do
an
allocation
of
the
same
size.
You
start
at
the
same,
offset
you
fail
over
and
over
and
over
again,
and
then
you
know
until
you
actually
do
a
different
search
and
for
a
different
size.
You
you
you
just
waste
time
and
you're
fit.
A
So
that
was
the
big
win.
This
is
still
a
win.
I
think,
and
it
makes
it
easier
to
understand
what's
going
on,
but
we
we
can.
We
can
be
a
little
more
lazy
about
it
now.
We
don't
need
it
immediately
for
quincy,
so
igor,
and
I
have
been
just
having
discussion
in
there
mostly
about
getting
rid
of
the
debug
code,
but
it's
do
not
merge
right
now,
so
we
should
be
okay
for
the
moment.
A
Let's
see,
but
in
terms
of
allocators,
I
think
we
still
have
a
lot
of
work
to
go
back
and
look
at
behavior,
but
but
yeah
not
not
for
today.
Okay,
so,
let's
see
next
is
maintain
free
list
type
in
ncb
mode,
so
gabby.
I
asked
gabby
about
this
a
little
while
ago
and
he
said
that
this
is
more
or
less
now
just
a
refactoring
pr.
A
A
couple,
more
suggestions
about
wording
and
and
kind
of,
I
think
the
latest
was
looking
at
clock,
speed
versus
number
of
cores
in
terms
of
the
the
monitor
the
manager
or
something
so
anyway,
people
are
looking
at
that
and
talking
about
getting
that
all
all
right,
so
that
was
that
was
it.
That
was
all
I
had.
I
didn't
quite
make
it
through
the
no
file.
I've
been
trying
to
do
too
many
things
at
once,
but
usually
the
stuff
at
the
end
doesn't
see
a
whole
lot
of
updates.
A
D
D
So
basically,
we
had
a
customer
on
a
pretty
new
cluster.
We
didn't
have
too
much
going
on
there
yet,
but
we
had
one
customer
using
veeam
that
started
hitting
our
cluster
really
hard
was
doing.
I
mean
pretty
hard
was
doing
like
50
to
100
megabytes
per
second
of
writes
for
a
few
weeks,
and
then
we
started
noticing
that
it
was
pausing
like
every
six
minutes
and
then
restarting
again
and
we
ended
up
finding.
D
D
So
the
pr
basically
just
avoids
that
first,
by
checking
whether
the
range
passed
down
from
blue
store
can
necessarily
be
only
on
a
single
column,
family
shard,
due
to
the
hashing
paradigm,
and
also
prevent
uses
the
upper
bound
setting
and
rocks
db
to
prevent
from
iterating
over
anything.
Above
the
o
map
of
that
particular
object.
A
Corey,
I
think
if
we
were
to
put
a
configuration
option,
it
would
be
that
this
would
be
the
default
behavior
and
that
would
only
be
a
short
circuit
for
people
to
be
able
to
like
turn
it
off
if
it
broke.
Something
is
that
would
that
be
reasonable?
Do
you
think,
or
do
you
think
we
just
have
it
blanket
on.
D
I
mean
I
think
I
mean
I
certainly
understand
the
sentiment
there,
of
putting
it
behind
a
configuration
flag
when
we're
trying
to
put
this
in
rather
quickly
at
the
end
of
this
kind
of
release
cycle
and
trying
to
get
it
out.
I
mean
that
makes
sense
to
me.
I
don't
know,
I
don't
know
what
the
extent
of
testing
is.
I
guess
that
is
being
done
prior
to
release
anyways
that
may
or
may
not
catch
it.
I
feel
like
from
my
perspective,
in
terms
of
risks
of
things
that
could
go
wrong.
D
A
Yeah
I
mean
it
on
one
hand.
It
feels
ridiculous
to
put
a
configuration
option
in
for
what
to
me
feels
like
a
bug
fix
here.
Right
like
this
is
this
is
a
major
issue
that
you've
you
figured
out
how
to
solve,
but
you
know
there
there
is
like
this
knit.
You
know
nagging
voice
in
the
back
of
my
head,
like
where
we've
seen
rocks
tv.
Do
things
we
really
didn't
expect
and
that's
I
don't
know
if
your
pr
could
result
in
that
or
some
breaking
something
else.
D
A
B
A
D
Yeah,
I'm
just
thinking
through
that
right
now
I
mean
from
the
upper
bound
lower
bound
standpoint.
I
said
no
for
sure,
because
I
can
just
not
set
those
options
on
the
racks
to
be
read:
options
simple,
this
condition
around
that.
So
that
seems
very
trivial.
I'm
trying
to
think
now
the
idea
of
skipping
isolating
it
to
a
single
column.
Family
should
also
be
easily
based
upon
a
configuration
flag
too
yeah,
because
I
can
just
give
that
condition
as
well,
so
it
should
be
a
minor
lift.
D
A
E
D
D
A
F
Yeah,
I
think
this
issue
is
urgent
enough
for
us
to
fix,
or
you
know,
lock
16
to
8..
I
would
like
to
get
the
test
run
started
for
master
as
soon
as
possible.
Given
that
the
dev
option
I
mean
I
mean,
given
that
the
default
behavior
is
on
by
default,
the
config
option.
Change
should
be
minor.
It
doesn't
hurt
to
run
it
through
a
first
round
of
testing.
F
F
D
A
Yeah,
I
I
just
put
my
approval
on
it.
Just
saying:
let's
get
the
the
option
to
disable
behavior
default
on
and
test
it
and
merge
it.
So
yeah
looks
good.
Thank
you
corey.
This
is
that
was
excellent,
excellent
work
and
can't
highlight
that
enough.
I,
I
suspect
that
this
is
going
to
reduce
the
the
workload
on
our
our.
You
know
our
consultant
folks,
quite
a
bit.
So
this
is
this
is
a
big
win.
Thank
you.
D
A
A
I
think
the
only
other
thing
I
had
is
I'm
looking
at
crimson
again
and
running
into
some
issues.
I've
got
a
pull
request
that
I'll
finish
later
today,
all
the
seastar
command
line
options
were
no
longer
being
parsed
correctly,
due
to
a
change
in
c-star
itself,
which
we
were.
We
were
kind
of
this
janky
thing
that
we
were
abusing
to
to
pass
stuff
to
them.
A
So
I'm
I'm
fixing
that,
and
I've
got
a
way
that
I
think
will
work
fairly
well,
but
then,
beyond
that
it
seemed
like
I
was
seeing
a
memory
leak
in
seastar
or
sorry
in
crimson.
Usually
I
saw
memory
growth
during
rights,
so
I
think
it's
on
the
right
path.
Radic
made
a
good
observation
this
morning.
That
potentially
was
the
way
the
alien
store
works.
We
may
be.
G
It's
not
even
a
hypothesis,
it's
just
a
long
shot.
Basing
on
my
on
my
experiments
when
when
we
were
when
we
were
trying
to
run
alien
star
and
bluester
with
the
c
stars
allocator
at
the
moment
it
got
the
situation
got
changed
significantly
because
because
a
sister
got
a
bunch
got
a
patch
that
basically
bypasses
the
sister
allocator
for
alien
threats.
Like
the
bunch
of
the
bands
we
have
in
alien
start.
G
G
So
it
turned
out
that
running
blues
the
running
blue
star
directly
with
the
very
limited
sister
allocator.
It's
not
our
way
to
go.
It's
not
a
good
idea
since
then,
of
course,
as
I
said
before,
sister
got
a
patch
that
basically
bypasses
the
sister
allocator
and
goes
directly
to
the
to
the
system.
One
short
work,
but
basically
just
a
hint
on
what
might
be
worth
initial
traffic
checking.
A
G
G
But
if
I
recall
correctly,
we
were
doing
that.
Maybe
I
guess
I
will
try
to
find
it
soon,
just
after
justin
typical
and
the
difference
was
pretty
big
between
between
using
the
system
allocator
and
the
system
equator,
because
initially,
before
sister
got
the
bypass
for
system.
Okay
for
the
system,
allocator,
we
were
linked.
We
were
disabling
this,
the
assisted
allocator
entirely
and
switched
the
just
for
the
sake
of
operating
booster.
We
switched
back
to
the
lipstick
provided
one
and
the
difference.
G
A
G
A
So
the
the
last
communications
I
had
with
them,
no
one
knew
what
firmware
we
should.
They
asked
me
which
one
I
wanted
to
use,
and
I
told
them
I
had
no
idea
which
ones
I
should
use,
because
I
don't
know
what
the
differences
are
and
so
that
they
were
trying
to
figure
out
which
firmware
they
thought
I
should
install
and
that
that's
kind
of
where
we
left
it.
A
Hopefully,
maybe
I
can
talk
to
someone
a
little
bit
more
and
and
figure
it
out.
I
think
he
was
of
the
opinion
that
we
should
get
the
latest
just
whatever
the
newest
was
and
put
that
on
there,
but
I
think
they
were
trying
to
wait
to
talk
to
some
of
the
engineers
in
in
korea
and
south
korea
to
to
just
verify
that
that
was
you
know
the
right
way
to
go.
A
The
one
thing
that's
kind
of
interesting
is
that
the
certain
drives,
which
are
basically
the
same
things
we
have
only
with
newer
firmware
and
a
slightly
different
driver
vision,
are
still
like
10
to
15
percent
faster
than
ours.
So
I
don't
know
if
that's
due
to
the
firmware
or
if
there
was
anything
else
that
changed,
but
they
just
consistently
get
just
slightly
higher
results
than
we
see
even
with
our
fixes,
and
they
weren't
suffering
the
same
issue
that
we
were
so
you
know.
Definitely
it
seems
like
something
something
is
different.
G
A
G
A
G
Am
a
afraid
we
cannot
it's
simply
too
limited:
it's
not
a
posix
compliant
memory.
Allocator.
First
of
all,
there
is
a
huge
limited.
The
the
biggest
the
most
important
limitation
is
that
you
can.
It
can
support
only
limited
and
constant
compact
undefined
number
of
threats,
and
it
doesn't
even
recycle
the
resources,
the
shards,
so
this
boils
down
into
the
number
of
all
threads.
It's
seen.
G
A
G
At
the
moment,
after
the
changes
in
systar,
we
can-
and
we
do
use
of
the
sister
allocator
in
the
sister
part
of
of
of
crimson
yeah
before,
if
we
had
to,
we
were
enforced
to
research,
the
ellipse
one
only
because
only
for
the
sake
of
hosting
bluestar.
Even
if
actually
somebody
picked
up
seanster
via
the
configuration
the
runtime
configuration
machinery
we
we
had,
we
were
using
since
the
the
ellipse
allocator
for
entire
process
for
all
parts,
also
the
sister
written
ones
after
the
change.
G
G
G
I
wouldn't
say
my
impression
is
that
the
the
the
performance
of
tc
malloc
will
be
somewhere
between
the
system
allocator
and
and
the
pt
my
lockers
too,
the
default
lipsy
ones
so
still
a
business
in
in
in
not
poking,
not
disabling,
the
system,
allocator
running
all
the
gizmo
and
all
the
system.
Gizmos
all
the
sister
worked
with
the
sister
allocator,
while
letting
the
alien
threats
in
alienster
to
use
pc
just
for
the
sake
of
booster.
G
G
G
A
Yeah,
most
mostly
I
was
just
trying
to
erratic,
I
was
just
trying
to
figure
out
like
has
the
behavior
now
changed
with
that
that
flag?
Like
does
it
at
one
point:
where
was
it
using
the
default
allocator
for
everything?
Is
it
just
alien
threads,
and
now
it
uses
only
for
alien
threads?
That's
what
I
was
trying
to
kind
of
okay.