►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Resource Management WG Deep Dive – Vishnu Kannan, Google (Intermediate Skill Level)
This session provides a deep dive into the features and technologies that the Kubernetes Resource Management Working Group has been working on recently. Specifically, this would include support for hardware devices like GPUs, improved performance via smarter CPU and Memory management, and overall compute resource extensibility. You will benefit from this session if you care about performance and performance sensitive workloads like Machine Learning.
About Vishnu
Vishnu Kannan is a Senior Software Engineer at Google. Vishnu received his Masters in ECE from Georgia Tech. He has been a systems engineer ever since he graduated. He hacked on the Linux Kernel for a couple of years at Cisco. He then worked on Borg at Google. He is currently an active maintainer in the Kubernetes community focussing on managing compute resources at scale.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Hey
everyone
welcome
I
was
told
that
this
slot
is
special
because
there's
like
four
or
five
really
interesting
talks
at
the
same
time,
so
I'm
surprised
and
I'm
happy
that
you
made
the
choice
to
be
here.
I
hope
I
can
give
you
enough
information
that
ensures
that
the
time
you're
spending
here
is
actually
valuable
for
you.
So
am
Bishnu.
A
A
A
A
A
Improve
compute
resource
management,
it
was
something
that
was
partially
being
tackled
before
the
working
group
was
formed.
What
we
were
mostly
focusing
on
was
like:
how
do
we
get
the
system
to
be
reliable?
How
do
we
get
the
note
to
be
really
reliable,
such
that
things
don't
fall
over?
Wait,
we're
only
focusing
on
reliability,
we're
not
focusing
on
anything
else
or
any
other
features
and
functionalities.
A
So
think,
last
year,
or
maybe
the
year
before,
cube
core
in
Seattle,
we
decided
that
okay,
we
need
to
start
spending
some
time
on
adding
functionality
and
adding
features
such
that
we
can
support
more
workloads,
more
applications
and
also
like
improve
the
experience
of
existing
supported
workloads
in
addition
to
just
reliability.
So
our
first
task
was
literally
to
go
ahead
and
like
figure
out
a
road
map
and
and
see
how
we
can
start
executing
and
what
the
priorities
are
and
so
on.
A
So
I
also
want
to
talk
about
the
community
because
I'm
a
representative
here,
but
there's
so
many
other
people
who
are
actually
actively
contributing
as
I
speak.
So
it's
it's
a
really
active
big
community
and
we're
all
like
genuinely
surprised
at
the
sheer
amount
of
interest
in
this
specific
area,
even
though
it's
a
sub
area
so
there's
more
than
30
plus
active
contributors.
A
First
for
Googlers,
we
always
look
at
board
and-
and
we
think
oh
we've
done
it
this
way
in
box-
should
we
just
do
the
same
thing
or
should
we
adapt,
but
some
of
the
problems
we
are
tackling
here
not
being
solved
in
bar,
and
so
we
don't
have
a
different
system
to
look
at
and
draw
a
parallel,
sometimes
like.
That's
the
why
I
wanted
to
highlight
that
some
of
the
problems
are
really
high.
I
feel
interested.
A
I
can
mention
a
few
of
them
after
the
talk
and
we
meet
bi-weekly
or
zoom,
and
then
our
in-person
meetings
that
are
approximately
once
a
year
also
I
want
to
show
a
picture
from
a
recent
in-person
meeting
that
we
had.
We
made
an
Iberia
who
hosted
our
our
most
recent
meeting
and
there's
a
world
like
forty
people
who
showed
up
and
we
actually
had
two
day-long
sessions,
and
so
it
was
just
a
highlight
that
there's
an
active
community
behind
this,
let's
keep
going
so
what
are
some
of
our
past
accomplishments?
A
So
we
spend
quite
some
time
on
computer
resource
extensibility.
So
the
way
cubed
is
was
maybe
six
months
back.
There's
a
situation
where,
if
you
want
to
introduce
any
new
resource,
you
have
to
go
change,
lots
of
code
components
and
for
those
of
you
here
who
have
tried
or
attempted
to
add
new
features
in
the
core.
You
know
like
how
rigorous
it
is
and
how
difficult
it
is
because
cumulus
wants
to
make
sure
it's
portable
and
it's
scalable
across
a
variety
of
environments.
So
it's
like
a
really
high
bar
to
add
something
into
the
core.
A
So
we
started
focusing
a
lot
on
extensibility
where,
in
order
to
like
implement
a
new
concept
or
a
new
feature,
let's
say
we're:
adding
support
for
a
new
device.
We
don't
have
to
go
and
change
the
core
completely.
So
we
decided
that
extensibility
is
a
really
important
thing
that
we
have
to
focus
on,
and
so
we
spend
a
great
deal
of
energy
getting
extensibility
to
to
work
and
also
not
just
work
in
a
sense
that
beat
them
or
that
it
works,
but
also
have
production
systems
that
are
running
through
these
extensions.
A
So
some
of
the
key
elements
that
were
added
verse,
we
introduced
this
new
concept
called
device
plugins,
which
is
currently
beta.
So
we
have
GPUs
that
are
supported
through
device
plugins
and
that
that
interface
is
it's
running
in
production
now,
and
so
we
have
quite
a
bit
of
runway
with
that
interface,
but
it's
beta
because
there's
so
many
other
use
cases
that
it
does
not
support.
Yeah
I'm
going
to
be
talking
a
little
bit
more
about
those
use
cases
in
detail,
but
just
to
give
you
an
idea
like
not
support
network
devices.
A
Now
our
storage
devices
or
nor
can
we
support
devices
that
have
to
be
passed
through
to
a
VM
guest,
for
example.
So
there's
still
a
long
way
for
us
to
go
there,
but
we
have
something.
That's
meeting
users
needs
today
and
we
also
made
some
changes
to
scheduler
extensions
such
that
you
can
now
introduce
like
your
own
node
level
or
cluster
level
resources
without
again
changing
a
system.
You
can
literally
like
drop
in
an
extension
point
which
would
then
go
plug
in
to
the
scheduler,
so
you
don't
have
to
write
a
new
scheduler.
A
We
did
some
work
on
CPU
scheduling
and
focus
here
was
to
like
get
rid
of
CFS
for
for
apps
that
are
really
really
latency
sensitive.
So
how
can
you
just
put
them
on
a
core
and
not
worry
about
those
apps
ever
getting
in
trouble
because
you
see
a
mess,
so
we
started
with
the
we
had
a
grand
goal
of
like
saying:
okay,
we'll
do
this
automatically,
so
we
will
figure
out
like
what
is
the
performance
of
a
given
process
or
given
set
of
processes.
A
We
observe
it
CPI
and
then
we'll
automatically
tune
everything,
but
that
seemed
like
a
multi-year
effort,
so
we
said:
okay,
we
first
start
with
just
static,
pinning
there
if,
if
a
part
shows
up,
but
it's
asking
for
integral
number
of
course,
then
we'll
just
give
it
a
single
core
or
like
whatever
number.
Of
course
it
asked
and
that's
it.
It
started
Lee
done
this.
A
If
there
is
fragmentation,
then
we
just
deal
with
it
and
then
and
that's
that's
state
of
the
world,
but
then
we
also
have
our
ambitious
goals
that
I
mentioned
earlier,
which
is
not
making
it
available
just
for
integral
course,
but
also
for
other
use
cases
such
that
the
user
doesn't
have
to
worry
about
fine-tuning,
CFS
or
fine-tuning
quota
and
so
on.
It's
like
it
just
works
and
we
can
present
to
the
user
what
sort
of
blatant
C's
they
can
expect
like
at
the
pic.
A
What
sort
of
tail
latency
is
the
system
can
guarantee
and
then
design
the
system
around
that?
So
that's
something
that
we
look
forward
to
doing
in
the
future.
But
what
we
have
now
is
just
static:
CP,
open,
a
user
added
support
for
huge
pages,
which
again
is
useful
for
quite
a
few
applications
which
again
suffer
from
the
regular
phl
occasional
agencies.
This
is
these
features
are
very,
very
important
for
really
latency
sensitive
apps,
but
for
the
regular
ones.
Maybe
you
don't
care?
A
A
A
So
what
are
some
of
the
future
projects?
So
we
want
to.
We
want
to
continue
with
with
compute
resource
extensibility.
We
want
to
make
the
API
really
feature-rich
such
that
a
you.
Don't
again
have
to
change
the
core,
we
have
to
loosely
like
write,
zero
lines
of
code
in
order
to
introduce
a
new
new
resource
into
the
system.
But
on
top
of
that
we
also
want
to
support
a
few
more
concepts
like
as
a
developer.
I,
don't
want
as
a
developer.
I
want
like
higher
level
primitives
than
lower
level
primitives.
A
But
to
give
you
an
example,
let's
say
I'm
having
let's
say,
having
a
bunch
of
different
network
devices
or
I
have
different
kinds
of
GPUs
or
different
kinds
of
CPUs.
All
I
care
about
is,
if
my
application
has
dependency
on
certain
instruction
sets
or
certain
properties
of
the
devices
that
wants
to
run
on
as
a
developer,
I
only
care
about
those
properties,
I,
don't
care
about
which
exact
device
and
running
on,
because
my
app
is
portable
in
theory,
so
I
can
take
it
and
run
it
anywhere
and
I
can
share
my
app
across
from
users.
A
But
if
I'm
writing
my
app
against
a
very
specific
set
of
resources,
then
it's
no
longer
portable
and
the
whole
cumulus
promise
is
like
out
the
door.
So
we
want
to
bring
the
balance
between,
on
one
hand
like
we
have
to
deal
with
the
reality
of
like
architectural
diversity.
On
the
other
hand,
we
also
want
to
have
separation
of
concerns.
So
how
do
we
bring
forth
such
a
system
where
users
can
as
a
developer,
I
can
just
describe
my
higher-level
needs
and
the
system
can
translate
that
into
lower-level
actual
concrete
resources?
A
So
that's
that's
one
of
the
that's
one
of
the
key
pieces.
We
want
to
enable
there's
been
some
active
work
going
on
here,
defining
api's
that
are
again
extensible
and
can
also
be
expressive
enough.
Users
can
say
here:
one
I
want
a
device
of,
so
it's
so
much
memory
of
the
Bandon
which
supports
say
avx2,
for
example,
and
then
we'll
figure
out.
A
What's
the
right
set
of
notes
to
skiddoo
of
those
pods
on
and
then
we
also
want
to
improve
the
extensions,
the
scheduler
level
and
at
the
node
level,
like
I,
said
earlier,
there
are
more
use
cases
that
we
are
not
able
to
support
and
there's
also
like
usability
issues
that
we
won't
address,
and
then
we
also
want
to
support
cluster
level
resources.
There's
no
such
concept.
A
Nowhere
with
the
schedule
extender
you
can
like
on
a
cluster
level
resource,
but
it's
still,
the
the
amount
of
maintenance
and
our
mode
of
development
necessary
to
introduce
a
simple
resource
is
quite
high.
So
you
want
to
change
that.
So
you
want
to
make
it
like
really
easy,
where
you
can
inject
a
cluster
level
resource
and
a
system
knows
how
to
deal
with
that,
and
we
also
want
to
support
network
devices.
A
This
is
like
a
really
hotly
discussed
topic
because
network
devices
they
both
network
and
devices,
and
so
they
span
multiple
abstractions
and
so
they're
a
little
bit
tricky
as
to
how
we're
going
to
abstract
them
in
that,
like
they're,
not
just
a
resource,
but
they
also
bring
forth
bring
along
some
other
baggage
which
that
working
industry
has
carried
for
so
long.
So
it's
like
how
do
you
draw
the
line
and
like
how
do
you
expose
it
to
the
end-user?
A
So
I
know
the
project
that
we
were
working
on
as
like
hardware,
topology
awareness
again.
This
is
something
that
traditionally
people
have
fine-tuned
manually,
where
you
find
your
app
to
run
on
a
specific,
Numenor
or
specific
set
of
CPUs,
and
you
choose
the
right
GPU
you
wanna
run
online
like
so
so
on
and
so
forth.
Right
like,
if
you
have
a
network
app,
you
choose
that
I
want
to
run
on
CPU
socket
zero.
For
example.
A
We
don't
want
users
to
do
that
like
we
just
want
them
to
choose
an
SLO
band
or
like
an
application
priority
band
and
the
system
would
automatically
place
them
on
the
right
right,
sort
of
nodes
with
the
site,
sort
of
properties
and
and
like
keep
fine-tuning
that
over
time.
So
this
was
something
that
we
very
at
least
Google
is
able
to
accomplish
and
boring,
and
we
had
like
quite
some
success
with
that.
A
So
we
want
to
like
bring
forth
again
that
that
set
of
fish
functionalities
into
communities
again,
but
we
are
also
dealing
with
newer
age
hardware
that
we
haven't
seen
so
far,
especially
in
ml,
well,
a
lot
of
the
general-purpose
hardware
or
going
away
and
then
special
purpose
hardware
as
a
showing
of
almost
like
every
month,
and
so
they
have
their
own
set
of
requirements
and
own
set
of
constraints.
So
we're
trying
to
model
cumulus
such
that
it
can
again
like
fit
different
needs,
ranging
from
raspberry
pies
to
the
high-end
machines.
A
We
want
to
support
cluster
level
and
node
level
scheduling
in
the
sense
that,
if
you
want
to,
we
want
the
notes
to
optimize
as
much
as
possible.
So
as
a
developer,
I
don't
have
to
care
about.
How
is
my
application
performing
because
I
know
for
a
fact
that
I'm
gonna
I'm
gonna
get
certain
level
of
pay
latencies,
because
the
system
has
been
benchmarked
and
system
has
been
set
up,
such
that
it
can
guarantee
that,
but
at
the
same
time,
I
was
already
improve
utilization
and
I.
A
Don't
want
I
don't
want
to
like
I,
don't
want
to
have
too
much
of
fragmentation.
So
then
you
might
want
to
take
a
higher
level
and
like
look
at
all
the
nodes
and
do
scheduling
a
little
bit
more
smartly.
So
we
only
we
want
to
empower
that
use
case
as
well,
and
we
also
want
to
have
like
performance
tracking
such
that
we
can
make
sure
you
don't
get
three
questions.
At
the
same
time,
you
can
also
like
keep
fine-tuning
the
system
and
identify
bugs
in
the
system
as
its
functioning
and
monitoring
is.
A
Another
hot
topic
like
we're
curious,
is
adding
lots
of
extensions
because
it
cannot
scale
to
meet
varied
use
cases
from
ranging
from
different
vendors
and
different
users
focusing
a
lot
on
extensibility,
but
we
are
not.
We
don't
have
a
good
extensibility
story
for
monitoring
and
logging
today,
so
this
working
group
is
trying
to
help
the
monitoring
part
of
it
by
by
figuring
out,
how
do
we?
How
do
we
decouple
cubelet
from
the
data
plane
for
collecting
metrics?
So
you
can.
A
You
can
literally
like
drop
in
a
plugin,
that's
been
given
to
you
by
a
vendor
and
monitoring.
Just
works
with
from
a
theist,
so
you
don't
have
to
change
anything
in
the
course.
So
we
want
to
work
towards
that
kind
of
that
kind
of
a
user
story
and
that's
part
of
the
part
of
the
effort.
We
also
want
to
do
application
performance
benchmarking
right
now.
We
don't
measure
anything,
we
don't
measure
performance
at
all
and
that's
not
a
good
place
for
curators
as
a
project
to
be
so
as
a
community.
A
We
are
also
investing
in
developing
black
box
measurements
to
inform
us
like
how
our
different
popular
applications
performing
like
how
is
memcache
deep
performing.
How
is
JBN
performing
across
like
most
common
environments,
and
we
want
to
like
track
those
metrics
make
it
available
publicly,
so
we
can
track
it
across
releases
and
across
future
changes.
A
A
A
A
Okay,
so
the
question
is:
what's
the
state
of
the
art
and
you
were
trying
to
be
a
little
bit
more
specific
with
GPOs
right,
okay,
because
that
might
help,
because
otherwise
the
space
is
too
large.
So
when
it
comes
to
GPUs,
we
actually
have
a
few
production
systems
like
I
said
earlier.
That
are
using
the
extensions
that
I
just
mentioned,
like
device
plugins
and
scheduler
extensions
in
order
to
make
GPUs
compatible
incubators
and
actually
function
in
a
production
ready.
Man.
A
A
The
question
is
that:
are
there
other
resources
that
have
the
same
support
now,
so
we
had
proof
of
concept
for
a
solar,
flare,
Nick
I
think
some
of
the
folks
in
winters
are
working
on
fvg.
Is
this
there's
a
gentleman
there
who
can
talk
a
lot
more
about
fpga
support
and
we've
seen
a
few
other
device
plugins
in
the
wild
like
we
get
links
for
them,
but
given
that
they
are
an
extension,
there's
no
need
for
developers
to
come
back
to
the
community
and
say
how
they
are
consuming
it.
A
So
we
don't
get
you're
not
like
all
that
information
is
not
available
to
us,
but
I
think
it's
the
early
stage
like
it's.
It's
been
just
six
months
and
it's
been
like
three
months
since
we
went
beta
I
think
this
is
when
people
are
ready
to
start
taking.
The
API
is
because
they
know
they
don't
have
to
change
it
every
three
months
and
so
I
would
I
would
expect
more
and
more
devices
show
up
in
the
next
six
to
six
months
to
a
year.
A
A
Okay,
so
the
question
is:
is
this
the
right
place
for
rescheduling,
or
is
this
a
right,
this
discussion
point
or
rescheduling
it
isn't?
It
is
not
in
that,
like
some
part
of
risky
doing,
is
it's
just
literally
a
cluster
level
'man
that
you're
running
and
so
from
a
cubist
point
of
view,
there
is
no
explicit
rescheduling
of
wads.
You
just
create
a
new
point
right
once
a
part
is
bound
to
a
node
and
started
there.
It's
it's
going
to
be
there,
there's
no
there's!
A
A
A
A
So
priority
is
more
geared
towards
that,
but
in
the
node
level
it
gets
a
little
difficult
because,
from
a
user
point
of
view,
it's
very
easy
for
you
to
think
in
terms
of
priority,
whereas
when
it
comes
to
QoS
classes,
it
does
not
represent
priority
right
like
you,
don't
you
don't
have
multiple
levels
there.
You
just
won't
have
only
like
three
levels
with
Cure's
classes,
so
it's
you.
Can
you
can
map
the
notion
of
like
an
intern
and
like
a
researcher
who
has
a
deadline
tomorrow
into
cures
classes?
A
Pod
like
an
intern
can
run
a
guaranty
pod,
but
that
doesn't
mean
that
part
has
to
continue
running
right,
like
I,
have
a
really
more
important
board
which
might
want
to
use
more
resources.
But
it's
important
and
I
have
like
consciously
made
a
choice
to
make
it
important.
So
in
that
sense
we
want
to
make
sure
that
you're
running
like
say
a
system
critical
part
like
some
some
you're
monitoring
add-ons,
for
example,
and
they
happen
to
exceed
their
request
a
bit.
A
We
don't
want
to
like
punish
them
just
because
of
that,
and
if
we
can
evict
a
lower
priority
part
that
might
actually
be
better
from
system
reliability
standpoint.
So
that's
a
fine
line
there.
So
my
short
answer
to
you
is:
we
still
need
cross
classes
because
we
want
to
represent
performance
there
salos
in
the
future.
So
that's
not
gonna
go
away
anywhere,
but
the
combination
of
Kwas
and
priority
classes
will
be
tricky.
A
A
The
if
there
is
no
guaranteeing
of
class
I
would
probably
consider
that
a
bug,
because
you
don't
want
to
once
you
choose
a
once.
You
choose
a
priority
class.
You
don't
want
to
go
and
make
parts
like
sex
a
ever
guarantee
parts
there,
because
maybe
you
have
like
a
map
like
a
best-effort
pod
that
you
wanna
make
first,
okay,.
A
Okay,
yeah,
the
way
the
croisé
classes
are
not
a
are
not
an
exquisite
concept
in
the
api
they're
derived
from
the
way
requests
and
limits
the
specified
so
that
that
derivation
is
still
in
the
system.
So
from
that
point
of
view,
that's
you
would
still
see
cost
classes,
but
how
are
they
actually
put
into
use
today?
That's
they
are
not
put
into
much
use
and
that's
what
we
are
working
on
with
this
working
group,
which
is
to
actually
start
stamping
essilor's
for
different
resources.
Yeah.
B
A
Yeah
the
question
is:
how
is
CPU
scheduling
expected
a
well
especially
CPU
quota,
because
it's
causing
pain
today
so
CPU
quota
is
not
something
you
originally
wanted
to
add.
I
think
they
were
like
a
few
use
cases
which
sort
of
forced
us
to
add
in
the
past.
So
it's
still
a
feature
you
can
opt
out
of
like
you
can
run
no
one's
fair.
You
can
turn
off
that
feature,
but,
like
most
major
clouds,
our
managed
distributions
of
kuvira's
are
are
actually
like,
turning
it
on
by
default.
A
So
there's
an
active
discussion
about
this
in
the
inner
github
issue,
so
my
my
opinion
on
that
is
that
I
would
prefer
disabling
CPU
quota
by
default,
because
I
really
don't
see
much
use
for
it.
It's
helpful
when
you
want
to
do
like
power
capping,
mostly
or
if
you're
running,
like
really
really
computer
intensive
tasks,
and
you
want
to
make
sure
like
they.
A
If
you
choose
integral
course,
then
in
the
future
we
can
be
a
little
bit
more
serious
where
we
can
isolate,
guarantee
pods
away
from
like
best
effort
and
worst
of
all
parts
such
that
they
get
like
more.
Better
guarantees
from
a
cpu
standpoint,
like
the
expectation
that
is
like
users
would
run,
say,
cache
thrashing
pods
as
as
best
effort,
and
it's
mostly
batch.
But
if,
if
people
are
running
patch
as
guarantee,
then
that's
not
going
to
work,
but
that
that
would
be
the
direction
I
would
try
to
convince
a
career.
You
know
towards.
A
A
Well,
I
mean
the
statement
was
what,
if
we
have
computer
intensive
and
laid
insensitive
and
said
they
didn't
see
sensitive
tasks
running
together.
So
when
we
are
expecting
CFS
to
function
pretty
well,
but
if
you're
hitting
issues
with
CFS
itself
either
like
should
go
fix
a
Linux
kernel
are
we
should
or
what
you
could
do
today
is
like
you
can
set
integral
core
limits
for
your
computer
intensive
tasks
that
way
they're
pin
to
CPU
cores
or
in
the
future.
A
When
we
are
actually
able
to
detect
application
performance,
we
might
be
able
to
isolate
them
on
two
different
sockets
or
different
course.
So
we
haven't
gone
into
that
future.
That's
why
we
want
to
get
to
where
you
can
observe
application
performance
patterns
and
we
can
observe
which
apps
are
victimizing
what
apps,
and
so
we
can
isolate
them
from
a
system
point
of
view
rather
than
having
the
users
manually
tune.
All
of
this.
A
Sure
the
next
statement
was
like:
what
do
we
do
that
tuning
cpu
quota
period?
The
reason
why
it's
not
exposed,
because
it's
most
likely
an
application
property
and
not
a
third
node
property,
because
the
node
is
being
shot
just
like
you
said,
with
different
applications,
and
so
then
that
means
you
have
to
expose
it
through
the
API
and
that's
that's
exactly
the
wrong
direction.
A
A
The
question
was:
what
about
storage
and
storage
devices
specifically
and
how
are
they
going
to
be
exposed
story?
Disk
is
not
currently
in
the
radar,
because
there's
like
a
complete
different
set
of
storage
API
is
especially
with
the
introduction
of
CSI.
There's
a
lot
more
flexibility
when
it
comes
to
storage.
But
then,
when
it
comes
to
new
age
storage
devices
like
PCI
nvme
devices,
then
they
fall
into
the
same
bucket
as
the
rest
of
the
things
that
we're
dealing
with,
and
so
we
have
to
figure
out.
What
is
the?
A
A
Okay,
the
question
was:
would
it
make
sense
to
have
a
single
unified
extension
point
across
all
different
kinds
of
devices
like
storage
network
and
compute?
That's
again,
I
think
there's
some
history
behind
it
in
that
not
all
storage
devices
care
about
a
care
about
like
topology,
maybe
not
all
Network
Devices
care
about
it.
So
I
think
I
think
the
new-age
high
performance
computing
applications,
especially
driven
by
like
AI
nml.
Those
are
the
ones
that
are
pushing
for
all
these
requests
to
become
important,
but
otherwise
there's
no
importance
for
convergence
there.
A
But
at
least
from
an
operator
point
of
view,
tim
has
been
Tim.
Hawke
has
been
pushing
quite
a
bit
for
unifying
the
way
vendors
are
building
extensions
and
and
how
they
are
packaged
so
that
they
can
at
least
be
deployed
together.
Even
though
there
are
three
different
extension
points,
but
when
it
comes
to
hardware,
topology,
I,
I
guess
we'll
have
to
start
with
compute
first
and
then
extend
it
to
the
rest
of
the
resources
we
all
time.
Okay,
I'm
gonna
be
out
right
next
to
the
door.
We
are
out
of
time.