►
From YouTube: CDS Infernalis (Day 2.2) -- Cache Tier Improvements
Description
Videos from Ceph Developer Summit: Infernalis (Day 2.2)
04 March 2015
https://wiki.ceph.com/Planning/CDS/Infernalis_(Mar_2015)
B
So
the
general
theme
here
is
just
the
cash
cheering
and
how
to
make
it
better.
The
whole
bunch
of
work
was
done
over
the
hammer
cycle
by
the
Intel
team
to
improve
cash.
Cheering
most
of
it
was
focused
on
the
Reid
side,
so
I
think
we're
doing
a
much
better
job
on
Reed's
of
avoiding
promotion.
B
The
sort
of
the
bummer
is
that
when
you
do
actually
decide
to
finally
promote
you
still
have
to
block
rights
because
so
the
object
doesn't
flight
can't
write
to
the
backend
one.
You
can't
really
write
to
the
cash
until
until
it's
wrote
it
so
that
that
isn't
really
going
to
go
away,
but
I
think
I
think
we're
sort
of
most
the
way
to
too
good
they're.
B
B
B
The
other.
The
other
scenario
would
be
where,
where,
if
you
have
a
right
through
cash,
meaning
that
on
Reed's
you
after
enough
reads-
you
promote
into
the
cache
tier.
But
if
you
get
any
rights,
you
would
just
delete
it
from
the
cast
here
and
push
it
that
back
down
to
the
base
dear
and
do
the
rights
there,
which
I
hear
from
the
DM
crypt
folks
at
least
things
work
pretty
well
for
a
lot
of
workloads.
B
So
that
would
be
an
option
too.
But
in
any
case
you
being
able
to
know
whether
or
not
we've
been
getting
reads
or
writes,
an
object
would
be
be
really
really
useful.
I'm,
the
other
sort
of
dimension
would
be
whether
the
rights
that
we
get
are
sequential
or
random
would
be
good
to
know,
because
if
it's
always
like
full
sequential
writes
on
the
object,
then
it
might
as
well
stay
in
the
base
dear.
But
if
they're
random,
then
we'd
want
to
pull
them
into
the
cashier.
B
So
I
think
that
the
easy
way
to
address
that
would
just
be
to
extend
hit,
set
to
have
a
bunch
of
different
arguments
to
all
the
different
functions.
When
you
insert
something
so
you
know
whether
is
a
read
or
write
or,
as
maybe
a
sequential
read
or
write,
or
something
keep
track
of
that
and
or
you
can
make
the
implementation
just
basically
keep
like
in
like
two
parallel
hits.
That's
one
for
reads
and
a
different
hit
set
for,
writes
something
like
that.
B
All
right.
So
that's!
That's
the
that
I
think
the
simpler
part
of
the
proposal
and
I'd
be
I'd
be
curious
to
hear
what
what
everybody
else
sort
of
thinks.
Thanks
to
that,
whether
that
that
makes
sense
for
the
workloads
that
they're
sort
of
thinking
about
for
the
cases
of
cash
steering
and
or
whether
it
doesn't
doesn't
make
sense.
B
Okay,
so
the
the
second
half
of
this
and
the
one
that's
sort
of
less
well
defined
but
more
complicated,
is
how
we
can
just
make
hits
that's
better
so
that
the
real
limitation
is
there.
They
cover
a
sort
of
fixed
time
interval,
say
an
hour
and
they
only
tell
you
whether
there's
one
or
more,
they
don't
tell
you
how
many
and
there's
a
huge
difference,
Peter
an
object
that
was
read
once
during
an
hour
and
one
that
was
read.
B
You
know
I
two
thousand
times
during
the
hour
and
right
now
we
have
no
way
to
tell
the
difference.
The
recency
thing
we
did
means
that
the
first
read
we
won't
promote,
but
the
second
read
we
will,
or
maybe
the
first
hour
of
reads
we
won't
promote
at
the
second
hour
as
soon
as
we
hit
one
hour,
then
we'll
promote,
which
is
better
than
nothing.
But
it's
still
pretty
pretty
course.
It
would
be
nice
if
we,
if
we
could
sort
of
detect,
you
know,
tepid
objects,
vs,
vs,
hot
objects.
B
Well,
let
me
let
me
go
through
just
the
simple
option,
so
the
basic
idea
is
that
you
have
a
bloom
filter
that
you
put
the
cold
stuff
in
you'd:
have
a
map
of
a
hash
table
of
object,
name
or
maybe
the
hash
of
the
object.
I,
don't
really
know
or
care
to
the
count.
That's
the
the
hot
set,
and
you
also
have
a
similar
recent
set.
B
So
for
every
say
your
say
your
overall
intervals
an
hour,
maybe
every
minute
you
would
collect
a
bunch
of
stuff
in
the
hash
table
and
then
after
that
minute,
you
basically
take
everything
that
is
above
some
median
or
threshold
number
of
items
and
put
that
in
the
in
the
recent
count.
But
that's
sort
of
here
you're,
the
hotter
warmer
objects
to
get
an
explicit
count
and
everything
that's
below
some
threshold.
You
just
dump
it
in
the
bloom
filter
because
if
it's
only
add
like
difference
between
one
request
and
twelve
request,
doesn't
matter
that
much.
B
But
if
you
have
10,000
is
then
that's
within
the
hot
one,
and
then
you
just
repeat
that
over
the
course
of
the
hour
and
over
that
period,
all
the
cold
stuff
would
end
up
in
this
bloom
filter.
It's
all
cold
and
the
hot
stuff
wouldn't
would
have
an
explicit
count
and
then
your
and
then
your
policy
decision
could
be.
You
know
if
it's
if
it's
depending
on
how
hot
it
is
or
if
it's,
if
it's
in
the
hot
setting
up
the
warm
set,
I
guess
then
you
would
then
you
to
promote
so.
B
Sorry
but
yeah
so
like
so
then
so
then,
basically
your
yes,
this
would
be.
The
promote
decision
on
read,
for
example,
would
say
after
I
have
a
hundred
after
I've
seen
100
reads
on
this
object,
then
I'll
promote
it,
but
the
first
99
a
won't
something
that's
opposed
to
the
second
read
or
promote
it
yeah
as
I'm,
not
sure
how
accurate
it
actually
has
to
be
like
it's.
Something
really
simple
might
be
good
enough,
so
I
covered.
A
B
A
Ahead,
let's
go
to
say
would
if
we
had
an
estimator
for
what
the
90th
percentile
hotness
was.
That
would
give
us
a
background
that
we
could
so.
The
risk,
I
think,
is
that
we
have
some
kind
of
oscillating
hots
up
where
every
em
requests
or
something
we
have
set.
A
is
hot
than
set
vias
hot
than
set,
see
us
out
and
said:
I
happens
that
the
Assad
and
set
C
is
up.
A
B
A
A
B
Dare
dare
you
have
to
hash?
That's
one
of
them.
It
is
cycled
every
every
minute
and
every
every
minute
you
take
the
top
percentile
and
you
dump
it
in
the
and
you
accumulate
it
or
always,
but
that
one
that
one,
you
don't
trim
that
when
you,
maybe
maybe
you
would
trim
it
if
it
if
it
got
too
big
because
I'm
just
hard,
it's
just
hard
to
tell
how
big
it
is.
How.
B
I
mean
even
if
you
did
and
you
trimmed
it
yeah
I,
guess
yeah
right,
so,
okay,
so
a
corollary
of
this
was
that
that
paper
that
we
saw
at
fast
that
was
estimating.
Was
it
something
curve?
It's
like
the
minimum
Oh
miss
rate
curve.
That
was
a
esta
mating
that
which
basically
tells
you
how
big
these
sets
should
be
so
I
think
that
would
be
a
really
useful.
It
would
be
useful
because
it
would
tell
us
how
big
our
cash
pool
should
be
relative
to
our
overall
pool
for
one.
B
It
would
also
tell
us,
within
a
cashier
how
big
these
the
hot
set
should
be
relative
to
the
this
cold
should
really
be
called
warm
I.
Think
it's
not
cold
right.
B
I
went
and
started
reading
one
of
the
papers,
and
it's
it's
like
this
weird.
It's
like
hashes
of
hashes
with
like
a
hash
set
whatever
it's
all.
It's
all
crazy.
It
reminds
me
of
bloom
filters,
but
like
in
three
dimensions.
So
probably
we
could
just
sort
of
find
an
implementation
to
one
of
these
or
go
like
pick
a
optics
pick,
an
approach
in
like
this,
but
I
think.
The
main
thing
is
that
we
could
just
go.
Do
some
reading
and
probably
find
a
good
solution
here.
B
You
see
him
wants
to
sell
it
to
me
yeah
that
was
that
was
really
annoying.
As
Diane
yep
I
was
going
to
put
a
snarky
comment
in
the
etherpad,
but.
B
B
So,
oh
you
got
it:
okay,
so
they're
right,
so
I
guess,
there's
sort
of
three
things
here
then
I
mean
there's
the
I
mentioned
the
beginning.
We
should
just
take
all
the
right,
the
right
proxy
stuff.
That's
that
cheeky
already
did
and
they're
right
recency.
That's
all
just
get
that
in
there,
because
it's
it's
simple
and
it
works.
B
B
A
We
can
we
can
we're
going
to
know
well,
if
you
have
small,
sequential
writes
than
necessarily
their
pipelines
almost
kind
of
right.
So
that
means
we
already
have
stayed
around
for
the
object.
So
we
would
be
pretty
easy
for
us
to
notice
that
we
just
got
for
rights
on
the
same
object
may
be
in,
in
which
case
we
don't
want
to
promote
it.
We
just
want
to
proxy
it
right
right
back
to
the
second
story
and.
B
B
A
B
A
B
A
B
B
One
hits
up
or
just
have
more
than
one
of
them
right,
but
maybe
maybe
it's
maybe
the
implementation
is
more
efficient
at
storing.
You
know
three
counters
for
each
item,
as
opposed
to
three
totally
independent
Maps
note
I
mean
because
if
it's
counts
literally,
the
key
is
like
more.
Although
it's
really
just
a
hash
value.
A
B
A
Bloom
filter
counting
counting
bloom
filters
date
there.
They
look
like
bloom
filters
and
they
do.
You
know
weird
stuff,
yeah
statistics
on
the
buckets
to
make
a
decision
about
an
estimator
for
the
mr.,
particularly
Keys
count.
So
it's
not
like
the
number
of
keys
matters
in
that
kind
of
well,
it's
ya
know
it
would.
He
would
have
to
simply
store
more
than
one
of
these
boom
filters
or
emotional
filters.
All
right:
okay,
okay,.
B
Okay,
so
that's
the
first
thing.
The
second
thing
is
I
think
we
should
have
the
estimate.
The
cache
sizes,
DMRC
construction,
because
that'll
be
I,
think
useful
in
a
whole
bunch
of
different
ways:
yeah
and
then
the
third
thing
is
go
and
do
some
research
and
figure
out
which
which
approach
for
finding
frequent
items
and
data
streams
we
actually
want
to
do.
B
A
A
It
couldn't
you
just
generate
like
a
thousand
just
pick
arbitrarily
a
thousand
hash
values
and
query
the
council
knows
or
no
a
thousand
well
distributed,
object
names
inquiry.
The
council
knows
that
would
give
you
a
representative
the
distribution,
and
then
you
can
use
that
to
decide
whether
a
particular
one
is
on
the
top
mighty
90th
percentile.
That's.
A
B
B
A
What
we
should
actually
do
is
implement
a
literal
hits
up
that
simply
off
floats
into
the
level
DB,
because
that'll
tell
us
how
good
how
well
we
can
do
if
we
have
a
perfect
implement.