►
From YouTube: 2016-SEP-07 :: Ceph Performance Weekly
Description
Weekly collaboration call of all community members working on Ceph performance.
For full notes and video recording archive visit:
http://pad.ceph.com/p/performance_weekly
A
A
But
if
you
didn't
see
it,
it's
really
good.
You
can
pack
more,
but
after
we're
done
with
this,
the
other
one
that
that
is
really
neat
is
P.
Odors
a
crush
optimization.
It's
a
fun
little
little
way
to
get
a
nice
performance
boost
for
straw
too.
So
that
was
exciting
beyond
that
there's
a
couple
of
other
were
a
new
PRS
here.
I
haven't
really
looked
too
closely
at
the
other
ones,
but
yeah
see
a
couple
of
different
things:
updated
I.
C
C
C
Maybe
I
should
RS
there's
that
884
at
the
bottom.
The
use
course
time
of
the
log
really
like
to
get
that
one
rich
actually,
but
I
want
Adam
or
somebody
with
some
good
C++
food
to
deal
with
that,
so
it
could
be
a
runtime
option.
Okay,
we
talked
about
in
code
to
code
sure.
A
So
in
in
my
quest
for
trying
to
make
all
of
this
somewhat
faster
I
stumbled
a
little
while
go
on
I'm,
a
group
barrington
coding,
which
basically
is
instead
of
like
taking
every
single
bite
that
you're
walking
through
and
and
using
one
of
the
bits
to
tell
what
I
know
that
another
bite
follows
and
kind
of
drinking
the
encoding.
That
way.
The
idea
here
is
that
you
take
a
prefix
and
in
the
prefix
you
store
a
certain
number
of
bits
or
whether
or
not
a
certain
number
of
bytes
follow
forgiven.
A
Still
like
for
32-bit
values,
you
can
store
for
have
length
prefixes
in
one
bite
for
UN,
60
40.
You
could
do
two
or
you
can
do
five
in
two
bites.
So
this
is.
This
is
nice
for
a
couple
of
different
reasons.
One
is
it's
pretty
straightforward
in
terms
of
what
the
encoding
and
decoding
looks
like,
so
it's.
This
is
quite
a
bit
easier
to
do
for
the
compiler,
but
in
addition
to
that,
one
of
the
things
that
we
can
do
is
is
like.
A
Take
the
the
24-bit
case
and
say
screw
it
we're
just
going
to
use
a
32-bit
value
for
that,
because
it
doesn't
happen
that
often
instead
in
the
prefix
encode,
that
0
is
just
a
0
value.
So
now,
if
you
have
like
a
UN
60
40
that
actually
has
a
0
in
it,
instead
of
encoding
that
in
the
full
bite
you
can
actually
just
encode
the
0
value
in
Richmond.
C
A
Bits
yep
three
bits
and
prefix
and
you
could
do
the
same
thing
like
for
a
one
if
you
have
a
really
common
case
where,
like
zero
and
ones
show
up,
but
you
potentially
need
like
the
full
64-bit
range.
But
you
know
usually
that
doesn't
happen.
Then
you
could
make
a
specific
in
code,
optimization
that
that
steals
from
the
higher
you
know,
values
and
codes
that
we
fix
so.
C
C
C
D
A
C
C
B
A
The
nasty
thing
about
Thor
is
that
it
there's
all
kinds
of
like
potential
combinations
of
things
you
could
do
like
you
could
have
maybe
like
to
64-bit
values
and
three
32-bit
values
that
you
want
to
encode.
So
how
do
you?
How
do
you
hear
that
smart,
Lydian,
I'm
I'm,
hoping
that
maybe
with
some
template
magic
and
overloading
the
head,
hung
that
I
could
have
it
like
choose
smart
things
behind
the
scenes
and
just
kind
of
go
off
and
do
it?
But
it's
baby.
A
C
A
My
test
case
right
now
is
it's
actually
p
extent,
T
in
the
existing
Bluestar
code,
which
is
just
a
really
basic
one,
where
it's
64
bit
and
a
32-bit
value.
That's
not
an
ideal
case
for
this,
which
is
one
of
the
reasons
why
I'm
using
it
here
to
see
if
it's
actually
helping
at
all
in
a
knot.
I,
don't
know
case,
but
okay.
C
D
A
A
Agree
with
you
Alan
you.
D
A
D
Most
of
the
places
that
we're
dealing
with
here,
I
mean
most
of
the
literature,
is
about
encoding
sort
of
random
numbers
that
are
uncorrelated.
Most
of
our
space.
Optimizations
are
going
to
come
from,
noticing
correlations
in
the
data
and
detecting
those
things
like
gee,
there's
no
hole
in
the
L
extent
array.
So
you
know
half
of
the
view
that
I
don't
need
the
offset
and
the
size
and
we
need
one
of
them.
D
You
look
at
that.
I
suspect
is
going
to
you
know
it's
the
it's.
The
old
story.
You
can
do
micro,
optimization
or
algorithm
optimization,
and
usually
the
algorithm
is
the
big
winner
and
I.
Think
that's
clearly
true
here.
You
know:
I
think
that
we
got
to
pull
all
the
tricks
out
of
the
bag
to
eliminate
essentially
redundant
information
in
the
data
itself
and
then
once
that's
done,
then
we
can
worry
about
fancy
ways
to
encode.
It
I
suspect
those
will
turn
out
to
be
secondary
issues.
C
C
A
That's
probably
actually
a
good
test
case
right
now
for
this
as
it
currently
stands,
because
it's
it's
there's
a
bunch
of
like
64
bit
values
in
our
that
you
know
exactly
so,
if
you
can
just
walk
through
those,
if
assuming
that
we
needed
to
keep
them
or
we
wanted
to
keep
them
the
current
behavior.
That
would
be
a
good
case
for
this
right,
because
you're
really
now
that
might
be
at
a
time
yeah
well.
D
This
might
be
a
case
where
a
custom
merge
operator
gets
what
you
want,
because
you've
only
updated
3
out
of
50
fields.
So
you
know
you
record
those
three
deltas
and
the
rest
are
gone
completely.
You
know,
I
think
the
real
issue
is:
are
those
fields
really
needed
to
be
in
the
PG
stat?
What's
the
update
frequency
of
them?
You
know
the
question
really
is:
do
the
fields
need
to
be
updated
on
every
transaction
yeah?
That
way?
That's
the
real
core
of
the
issue,
and
you
know
that
either
they
do
or
they
dumb.
D
But
a
nice
to
have,
if
you
give
it
I,
think
it
boils
down
to
crash
the
consistency.
You
know
if
the
stat
is
slightly
off
across
a
crash,
that's
either
a
problem
or
not
a
problem,
and
you
know
if
it's
not
a
problem,
then
batching
the
things
up
and
updating
them.
You
know
every
tenth
operation.
Every
50th,
you
know
is
a
pretty
simple
optimization
that
you
leaves
all
the
rest
of
the
code
intact,
but
if
it
actually
needs
to
be
updated
on
every
transaction
from
a
cat
crash
correctness,
that's
a
different
problem.
D
C
C
Exactly
yeah,
unfortunately,
merge
operators
don't
help
because
we're
several
layers
of
the
stack.
This
is
an
attribute
on
an
object,
that's
stored
in
the
node,
so
we
can't
really
put
it
in
its
own
custom,
CCA's
key
space
about
a
bunch
of
like
weird
pakery,
but
I
think
it's
going
to
be
sort
of
kenya's,
but
it's
certainly
doable
to
just
separate
the
fields
that
update
every
operation
and
from
the
ones
that
don't
I
think
the
way
to
approach
this,
and
it's
not
going
to
be
that
bad.
C
But
it's
going
to
happen
up
in
the
OST,
but
even
when
we
do
update
the
part,
that's
not
frequently
updated
and
I,
don't
know,
I,
don't
know
if
it's
worth
it,
it
might
be
this.
The
group
encoding
might
help
there
I,
don't
know
that
it's
gonna
be
that
big
of
a
win.
If
it's
really
is
an
infrequent
update,
thanks
for
some
reparation,
sila
p
comment
anyway:
okay
well,
I
need-
maybe
that's
private.
That's
next
step,
though,
is
to
to
look
at
that
how
to
get
the
PG
stat
updates
separated
into
two
parts.
C
D
D
C
D
C
D
D
At
ability
issue
that's
going
to
get
super
ugly,
okay
and
I
suspect
you're
to
end
up
pushing
that
down
fairly
low
in
the
code.
Anyways
I'm
just
saying
that
it
might
actually
be
easier
to
do
emerge
operator,
even
though
you
might
have
more
code.
Did
you
change?
The
complexity
is
a
not
terribly
high
and
it
does
support
the
old
layouts.
C
D
C
Operator
has
to
be
like
a
clean
summation
over
like
a
vector
or
something
in
order
to
be
sort
of
Stanley
to
find,
and
that
structure
is
anything,
but
it's
I
mean
it
does
have
a
lot
of
you
and
60
for
us,
but
they're,
buried
and
mix
in
about
well
amongst
a
bunch
of
other
other
objects
that
are
variably
size.
So
it
doesn't
really
lend
itself
to
that.
Yet
I.
A
Guess
I
the
question
I
have
is
okay,
we're
talking
about
you
know
doing
things
like
separating
out
things
that
need
to
be
updated
all
the
time
versus
things
that
don't
need
to
be.
You
know
going
through
all
this
to
figure
out.
What
does
what
doesn't?
Is
it
really
less
work
to
go
through
all
that
or
you
know,
less
work
to
see
if
some
encode
d
code
optimizations
are
good
enough
for
the
time
being,
to
kind
of,
let
us
execute
Miller
yeah.
C
A
D
C
C
D
There
are
definitely
some
schemes
you
can
do
with
the
MMX
instructions
that
will,
if
you're
willing
to
abandon,
say
a
minimum
one
bite
and
coding.
Let's
say
that
your
your
minimum
encoding
is
is
say
two
bytes
for
small
values.
You
can
do
some
things
that
are
really
fast
with
with
the
event
X
instructions.
You
know
where
you
create
a
bike
mask
that's
one
bit
per
buying.
That
tells
you
which
ones
are
zeros
or
not.
You
know,
with
a
few
MMX
instructions
you
can
basically
encode
and
decode.
You
know
again
with
just
a
couple
instructions.
C
A
D
D
I
suspect,
the
the
you
know
I,
I
I'm
wondering
if
it's
actionable
so
first
of
all,
the
existing
variant
itself
could
be
sped
up
dramatically
by
unrolling
the
loot
first
of
all
guys.
Let's,
let's
be
realistic
here
and
Kylie.
You
know,
and
that
alone
would
be
the
huge
performance
boost
relative
to
what's
going
on,
but
you
know
so,
but
you
know
I
guess
what
I'd
say
here
is
the
have
we
examined
it
in
the
context
of
the
sharted
Oh
node
and
the
the
the
appender
improvements
to
understand.
D
A
A
D
A
It
did
so
in
the
the
shard
map,
sages
charred
map
code
and
what
I
was
able
to
get
to
run
because
I
can't
get
through
a
full
test,
unfortunately,
due
to
their
running
on
memory,
but
we,
it
still
looks
to
me
like,
potentially
that
will
provide
some
speed
up,
maybe
not
to
the
extent
that
it
did,
but
it
will
see
it
was.
It
was
faster,
but
not
in
which
that
which
that
the
sorry
done
yeah,
the
appender
I
think
will
still
provide
some
benefit.
I
have.
D
No
doubt
of
that
I
think
you
have
to
assume
that
we're
applying
that
I
think
you
have
to
look
at
this
particular
question.
After
all,
these
things
are
done.
I
guess,
I'm
skeptical,
that
the
low-level
int
encoding,
what's
the
via
the
current
y
ugliness
is
fixed,
is
actually
going
to
make
that
much
difference
in
the
greater
scheme
of
things,
because
you
know
I
think
with
the
Charlotte
encoding
you're
going
to
cut
the
shard
size
itself
as
the
biggest
way
to
go
solve
that
problem.
C
Think
I
think
we
should.
We
just
need
to
sequence
these
things
before
we
do
all
the
stuff
that
we
know
that
we're
going
to
do
before
we
do
the
stuff
that
we're
not
sure
whether
it's
going
to
help
I'll
say:
let's
merge
the
starting
stuff,
I
think.
Obviously
the
current
smallint
loops
can
be
unrolled.
That
seems
like
a
no-brainer
and
that's
like
a
an
easy
base
line
to
do
so.
C
I
would
do
that
right
away
too
and
then,
let's
focus
on
getting
the
new
the
new
framework
that
includes
fixing
the
offender
stuff
in
place.
I
think
those
are
going
to
be
the
biggest
wins
and
then,
after
that,
then
we
should
look
at
where,
where
you
swear
our
time
is
being
spent
and
then
so
we
can
invest
their
time
sort
of
intelligent.
It
yeah.
D
A
A
C
C
A
C
A
vector
of
stuff,
no
I
mean
there
are
the
like
internal
stats,
and
blue
of
us
are
doing
that,
but
it's
like
literally
a
vector
that
isn't
even
encoded
and
it
has
emerged
operator.
So
it's
like
it's
already
cheap,
so
I
don't
see
any
case
right
now.
That's
like
going
to
be
that.
Might
that
isn't
possibly
to
probably
already
going
to
be
addressed
by
some
other
change
that
we
have
on
the
right
now
yeah.
So
I
would
I
would
wait,
but
unrolling
all
the
encoding.
C
A
I
mean
no,
that
was
actually
kind
of
the
route
that
I
had
gone
with
it.
That
kind
of
the
the
optimization
I
had
ended
up
with
it.
That
I
didn't
like
that.
Much
but
was
okay
was
actually
switching
to
this
model,
where
you
have
a
prefix
in,
like
the
first
two
bits
for
like
a
UN,
32
or
whatever,
and
then
doing
either
six
six
bits
to
put
it
into
a
bite
14
to
put
it
into
a
UN
60
or
not.
D
That
think
is
where
we're
going
to
find
the
real
win,
because
I
suspect
you're
going
to
find,
for
example,
with
a
disc
address
that
your
disc
addresses
are
almost
always
going
to
be
five
bytes,
almost
always
you're
not
going
to
have
any
value
in
having
even
even
supporting
the
case
of
something
that's
three
bytes
or
two
bites.
It's
just
a
waste
of
encode
expense.
C
D
Which,
which
plays
to
the
current
scheme
of
looking
at
it
on
a
per
field
basis,
rather
than
trying
to
combine
multiple
fields
with
some
kind
of
temporary
wizardry,
which
I
think
could
certainly
be
done?
I'd
like
to
you
know
again,
I
think
there
a
fair
of
investment
of
energy
there
and
I'd
like
to
see
us
get
these
other
things
out
of
the
way
before
we
go
tackle
that
which
is
it
to
say,
it'll
come
that
won't
come
back.
C
A
C
I'm
barato
just
sent
me
the
his
latest
branch.
It's
not
building
it.
He
had
some
questions,
I'm
going
to
review
that
next
and
probably
get
Sam
just
take
a
look
at
it
too,
because
I
think
that's
probably
gonna
be
the
next
big
step,
but
I
think
in
the
meantime,
that
the
thing
that
we
can
do
that
is
a
known
good,
win
or
whatever
is
just
unroll.
Those
loops
in
this
well
yeah.
D
C
Okay:
okay,
okay,.