USENIXOSDI2010年论文集（ProceedingsofUSENIXOSDI2010）资源-CSDN文库

共32个文件

pdf：32个

操作系统

OSDI

USENIX

4星 · 超过85%的资源需积分: 10 135 浏览量 2010-11-11 16:06:26 上传评论 2 收藏 16.23MB RAR 举报

资源推荐

资源详情

资源评论

收起资源包目录

USENIX Symposium on Operating Systems Design and Implementation 2010.rar （32个子文件）

USENIX Symposium on Operating Systems Design and Implementation 2010

Virtualization

mClock_ Handling Throughput Variability for Hypervisor IO Scheduling.pdf 373KB

The Turtles Project_ Design and Implementation of Nested Virtualization.pdf 253KB

Virtualize Everything but Time.pdf 1.16MB

Cloud Storage

Depot_ Cloud Storage with Minimal Trust.pdf 315KB

SPORC_ Group Collaboration using Untrusted Cloud Resources.pdf 772KB

Comet_ An Active Distributed Key-Value Store.pdf 274KB

Systems Management

Enabling Configuration-Independent Automation by Non-Expert Users.pdf 693KB

AUTOMA~1.PDF 171KB

Production Networks

Building Extensible Networks with Rule-Based Forwarding.pdf 960KB

ONIX_A~1.PDF 930KB

Can the Production Network Be the Testbed.pdf 1007KB

Mobility

TAINTD~1.PDF 836KB

STARTR~1.PDF 333KB

Kernels_Past, Present, and Future

An Analysis of Linux Scalability to Many Cores.pdf 217KB

FLEXSC~1.PDF 661KB

TRUSTA~1.PDF 566KB

Deterministic Parallelism

Deterministic Process Groups in dOS.pdf 322KB

STABLE~1.PDF 302KB

Efficient System-Enforced Deterministic Parallelism.pdf 592KB

Security Technologies

Intrusion Recovery Using Selective Re-execution.pdf 518KB

STATIC~1.PDF 209KB

Accountable Virtual Machines.pdf 471KB

Concurrency Bugs

Effective Data-Race Detection for the Kernel.pdf 483KB

Bypassing Races in Live Applications with Execution Filters.pdf 384KB

Ad Hoc Synchronization Considered Harmful.pdf 191KB

Inside the Data Center, 2

Reining in the Outliers in Map-Reduce Clusters using Mantri.pdf 3.66MB

LARGE-~1.PDF 219KB

TRANSA~1.PDF 224KB

PICCOL~1.PDF 178KB

Inside the Data Center, 1

Availability in Globally Distributed Storage Systems.pdf 389KB

Finding a Needle in Haystack_ Facebook's Photo Storage.pdf 312KB

NECTAR~1.PDF 1.39MB

Reining in the Outliers in Map-Reduce Clusters using Mantri

Ganesh Ananthanarayanan

†⋄

Srikanth Kandula

†

Albert Greenberg

†

Ion Stoica

⋄

Yi Lu

†

Bikas Saha

‡

Edward Harris

‡

†

Microso Research

⋄

UC Berkeley

‡

Microso Bing

Abstract– Experience from an operational Map-Reduce

cluster reveals that outliers signicantly prolong job com-

pletion. e causes for outliers include run-time con-

tention for processor, memory and other resources, disk

failures, varying bandwidth and congestion along net-

work paths and, imbalance in task workload. We present

Mantri, a system that monitors tasks and culls outliers us-

ing cause- and resource-aware techniques. Mantri’s strate-

gies include restarting outliers, network-aware placement

of tasks and protecting outputs of valuable tasks. Using

real-time progress reports, Mantri detects and acts on out-

liers early in their lifetime. Early action frees up resources

that can be used by subsequent tasks and expedites the job

overall. Acting based on the causes and the resource and

opportunity cost of actions lets Mantri improve over prior

work that only duplicates the laggards. Deployment in

Bing’s production clusters and trace-driven simulations

show that Mantri improves job completion times by .

 Introduction

In a very short time, Map-Reduce has become the domi-

nant paradigm for large data processing on compute clus-

ters. Soware frameworks based on Map-Reduce [

, ,

] have been deployed on tens of thousands of machines

to implement a variety of applications, such as building

search indices, optimizing advertisements, and mining

social networks.

While highly successful, Map-Reduce clusters come

with their own set of challenges. One such challenge is

the oen unpredictable performance of the Map-Reduce

jobs. A job consists of a set of tasks which are organized in

phases. Tasks in a phase depend on the results computed

by the tasks in the previous phase and can run in paral-

lel. When a task takes longer to nish than other similar

tasks, tasks in the subsequent phase are delayed. At key

points in the job, a few such outlier tasks can prevent the

rest of the job from making progress. As the size of the

cluster and the size of the jobs grow, the impact of outliers

increases dramatically. Addressing the outlier problem is

critical to speed up job completion and improve cluster

eciency.

Even a few percent of improvement in the eciency

of a cluster consisting of tens of thousands of nodes can

save millions of d ollars a year. In addition, nishing pro-

duction jobs quickly is a competitive advantage. Doing

so predictably allows SLAs to be met. In iterative mod-

ify/ debug/ analyze development cycles, the ability to it-

erate faster improves programmer productivity.

In this paper, we characterize the impact and causes

of outliers by measuring a large Map-Reduce production

cluster.  is cluster is up to two orders of magnitude

larger than those in previous publications [

, , ] and

exhibits a high level of concurrency due to many jobs si-

multaneously running on the cluster and many tasks on

a machine. We nd that variation in completion times

among functionally similar tasks is large and that outliers

inate the completion time of jobs by 34% at median.

We identify three categories of root causes for outliers

that are induced by the interplay between storage, net-

work and str ucture of Map-Reduce jobs. First, machine

characteristics play a key role in the performance of tasks.

ese include static aspects such as hardware reliabil-

ity (e.g., disk failures) and dynamic aspects such as con-

tention for processor, memory and other resources. Sec-

ond, network characteristics impact the d ata transfer rates

of tasks. Datacenter networks are over-subscribed leading

to variance in congestion among dierent paths. Finally,

the specics of Map-Reduce leads to imbalance in work –

partitioning data over a low entropy key space oen leads

to a skew in the input sizes of tasks.

We present Mantri1, a system that monitors tasks and

culls outliers based on their causes. It uses the follow-

ing techniques: (i) Restarting outlier tasks cognizant of

resource constraints and work imbalances, (ii) Network-

aware placement of tasks, and (iii) Protecting output of

tasks based on a cost-benet analysis.

e detailed analysis and decision process employed by

Mantri is a key departure from the state-of-the-art for out-

lier mitigation in Map-Reduce implementations [

, ,

]; these fo cus only on duplicating tasks. To our knowl-

edge, none of them protect against data loss induced re-

computations or network congestion induced outliers.

Mantri places tasks based on the locations of their data

sources as well as the current utilization of network links.

On a task’s completion, Mantri replicates its output if the

1From Sanskrit, a minister who keeps the king’s court in order

benet of not having to recompute outweighs the cost of

replication.

Further, Mantri performs intelligent restarting of out-

liers. A task that runs for long because it has more work

to do will not be restarted; if it lags due to reading data

over a low-bandwidth path, it will be restarted only if a

more advantageous network location becomes available.

Unlike current approaches that duplicate tasks only at the

end of a phase, Mantri uses real-time progress reports to

act early. While early action on outliers frees up resources

that could be used for pending tasks, d oing so is nontriv-

ial. A duplicate may nish faster than the original task

but has the opportunity cost of consuming resources that

other pending work could have used.

In summary we make the following contributions.

First, we provide an analysis of the causes of outliers in

a large production Map-Reduce cluster. Second, we de-

velop Mantri, that takes early actions based on under-

standing the causes and the opportunity cost of actions.

Finally, we perform an extensive evaluation of Mantri and

compare it to existing solutions.

Mantri runs live in all of Bing’s production clusters since

May . Results from a deployment of Mantri on a pro-

duction cluster of thousands of servers and from replay-

ing several thousand jobs collected on this cluster in a

simulator show that:

• Mantri reduces the completion time of jobs by 32 % on

average on the production clusters. Extensive simula-

tions show that job phases are quicker by 21% and 42%

at the th and th percentiles. Mantri’s median re-

duction in completion time improves on the next best

scheme by .x while using fewer resources.

• By placing reduce tasks to avoid network hotspots,

Mantri improves the completion times of the reduce

phases by 60%.

• By preferentially replicating the output of tasks that are

more likely to be lost or expensive to recompute, Mantri

speeds up half of the jobs by at least 20% each while

only increasing the network trac by 1%.

 Background

We monitored the cluster and soware systems that sup-

port the Bing search engine for over twelve months. is

is a cluster of tens of thousands of commodity servers

managed by Cosmos [

], a proprietary upgraded form of

Dryad []. Despite a few dierences, implementations

of Map-Reduce [

, , , ] are broadly similar.

Most of the jobs in the examined cluster are written

in Scope [

], a mash-up language that mixes SQL-like

declarative statements with user code. e Scope com-

piler transforms a job into a workow– a directed acyclic

graph where each node is a phase and each edge joins a

phase that produces data to another that uses it. A phase

is a set of one or more tasks that run in parallel and per-

form the same computation on dierent parts of the in-

put stream. Typical phases are map, reduce and join. e

number of tasks in a phase is chosen at compile time. A

task will read its input over the network if it is not avail-

able on the local disk but outputs are written to the local

disk. e eventual outputs of a job (as well as raw data) are

stored in a reliable block storage system implemented on

the same servers that do computation. Blocks are repli-

cated n-ways for reliability. A run-time scheduler assigns

tasks to machines, based on data locations, dependence

patterns and cluster-wide resource availability. e net-

work layout provides more bandwidth within a rack than

across racks.

We obtain detailed logs from the Scope compiler and

the Cosmos scheduler. At each of the job, phase and task

levels, we record the execution behavior as represented

by begin and end times, the machines(s) involved, the

sizes of input and output data, the fraction of data that

was read across racks and a code denoting the success or

type of failure. We also record the workow of jobs. Ta-

ble

 depicts the random subset of logs that we analyze

here. Spanning eighteen days, this dataset is at least one

order of magnitude larger than prior published data along

many dimensions, e.g., number of jobs, cluster size.

 e Outlier Problem

We begin with a rst principles approach to the outlier

problem, then analyze data from the production cluster

to quantif y the problem and obtain a breakdown of the

causes of outliers (§). Beginning at the rst principles

motivates a distinct approach (§

) which as we show in §

signicantly improves on prior art.

. Outliers in a Phase

Assume a phase consists of n tasks and has s slots. Slot is a

virtual token, akin to a quota, for sharing cluster resources

among multiple jobs. One task can run per slot at a time.

On our cluster, the median ratio of

is 2.11 with a stdev

of 12.37. e goal is to minimize the phase completion

time, i.e., the time when the last task nishes.

Based on data from the production cluster, we model

, the completion time of task i, as a function of the size

of the data it processes, the code it runs, the resources

available on the machine it executes and the bandwidth

available on the network paths involved:

= f (datasize, code, machine, network) . ()

Large variation exists along each of the four variables

leading to considerable dierence in task completion

times. e amount of data processed by tasks in the same

phase varies, sometimes widely, due to limitations in di-

viding work evenly. e code is the same for tasks in a

Dates Phases Jobs Compute Data Network

-’

x 10

(years) (PB) (PB)

May , .  . . .

Jun ,

.  . . .

Jul ,

.  . . .

Aug ,

.  . . .

Sep ,

.  . . .

Oct ,

.  . . .

Nov ,

.  . . .

Dec ,

.  . . .

Jan ,

.  . . .

Table : Details of the logs from a production cluster consisting

of thousands of servers.

phase, but diers signicantly across phases (e.g., map

and reduce). Placing a task on a machine that has other

resource hungry tasks inates completion time, as does

reading data across congested links.

In the ideal scenario, where every task takes the same

amount of time, say T , scheduling is simple. Any

work-conserving schedule would complete the phase in



⌈

⌉ × T



. When the task completion time varies, how-

ever, a naive work-conserving scheduler can take up to



+ max t



. A large variation in t

increases the

term max t

and manifests as outliers.

e goal of a scheduler is to minimize the phase com-

pletion time and make it closer to

. Sometimes, it

can do even better. By placing tasks at less congested ma-

chines or network locations, the t

’s themselves can be

lowered. e challenge lies in recognizing the aspects that

can be changed and scheduling accordingly.

. Extending from a phase to a job

e phase structure of Map-Reduce jobs adds to the vari-

ability. An outlier in an early phase, by delaying when

tasks that use its output may start, has cumulative eects

on the job. At barriers in the workow, where none of

the tasks in successive phase(s) can begin until all of the

tasks in the preceding phase(s) nish, even one outlier

can bring the job to a standstill2. Barriers occur primar-

ily due to reduce operations that are neither commuta-

tive nor associative [

], for instance, a reduce that com-

putes the median of records that have the same key. In

our cluster, the median job workow has eight phases and

eleven edges,  are barriers (number of edges exceeds

the number of phases due to table joins).

Dependency across phases also leads to outliers when

task output is lost and needs to be recomputed. Data loss

happens due to a combination of disk errors, soware er-

2ere is a variant in implementation where a slot is reserved for

a task before all its inputs are ready. is is either to amortize the

latency of network transfer by moving data over the network as soon

as it is generated [

, ], or compute partial results and present answers

online even before the job is complete [

]. Re gardless, pre-allocation

of slots hogs resources for longer periods if the input ta sk(s) straggle.

Extract

22K

Partition

13K

Aggregate

51K

Barrier

File

System

(a) Partial workow with the number of tasks in each phase

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 0.1 0.2 0.3 0.4 0.5

# Running Tasks

(Normalized by max in phase)

Time (Normalized by Job Lifetime)

Extract

Partition

Aggregate

(b) Time lapse of task execution (R=Recomputes, B=Barrier).

Figure : An example job from the production cluster

rors (e.g., bugs in garbage collectors) and timeouts due to

machines going unresponsive at times of high load. In

fact, recomputes cause some of the longest waiting times

observed on the production cluster. A recompute can cas-

cade into earlier phases if the inputs for the recomputed

task are no longer available and need to be regenerated.

. Illustration of Outliers

Figure

(a) shows the workow for a job w hose structure

is typical of those in the cluster. e job reads a dataset

of search usage and derives an index. It consists of two

Map-Reduce operations and a join, but for clarity we only

show the rst Map-Reduce here. Phase names follow the

Dryad [

] convention– extract reads raw blocks, parti-

tion divides data on the key and aggregate reduces items

that share a key.

Figure

(b) depicts a timeline of an execution of this

workow. It plots the number of tasks of each phase that

are active, normalized by the maximum tasks active at any

time in that phase, over the lifetime of the job. Tasks in

the rst two phases start in quick succession to each other

at ∼., whereas the third starts aer a barrier.

Some of the outliers are evident in the long lulls before

a phase ends when only a few of its tasks are active. In par-

ticular, note the regions before x∼. and x∼.. e spike

in phase  here is due to the outliers in phase  holding

on to the job’s slots. At the barrier, x∼., just a few outliers

hold back the job from making forward progress. ough

most aggregate tasks nish at x∼., the phase persists for

another .

e worst cases of waiting immediately follow recom-

putations of lost intermediate data marked by R. R ecom-

putations manifest as tiny blips near the x axes for phases

that had nished earlier, e.g., phase  sees recomputes at

x∼. though it nished at x∼.. At x∼., note that aggre-

gate almost stops due to a few recomputations.

We now quantify the magnitude of the outlier problem,

before presenting our solution in detail.

 Quantifying the Outlier Problem

We characterize the prevalence and causes of outliers and

their impact on job completion times and cluster resource

usage. We will argue that three factors – dynamics, con-

currency and scale, that are somewhat unique to large

Map-Reduce clusters for ecient and economic opera-

tion, lie at the core of the outlier problem. To our knowl-

edge, we are the rst to report detailed experiences from

a large production Map-Reduce cluster.

. Prevalence of Outliers

Figure

(a) plots the fraction of high runtime outliers and

recomputes in a phase. For exposition, we arbitrarily say

that a task has hig h runtime if its time to nish is longer

than .x the median task duration in its phase. By re-

computes, we mean instances where a task output is lost

and dependent tasks wait until the output is regenerated.

We see in Figure

(a) that  of phases have more

than  of their tasks as outliers. e gure also shows

that  of the phases see no recomputes. ough rare,

recomputes have a widespread impact ( §

.). Two out of

a thousand phases have over  of their tasks waiting for

data to be recomputed.

How much longer do outliers run for? Figure

(b)

shows that  of the runtime outliers last less than .

times the phase’s median task duration, w ith a uniform

probability of being delayed by between .x to .x. e

tail is heavy and long–  take more than x the me-

dian duration. Ignoring these if they happen early in a

phase, as current approaches do, appears wasteful.

Figure

(b) shows that most recomputations behave

normally,  of them are clustered about the median

task, but  take over x longer.

. Causes of Outliers

To tease apart the contributions of each cause, we rst de-

termine whether a task’s runtime can be explained by the

amount of data it processes or reads across the network3.

If yes, then the outlier is likely due to workload imbalance

or poor placement. Otherwise, the outlier is likely due to

resource contention or problematic machines.

Figure

(a) shows that in  of the phases (top right),

all the tasks with high runtimes (i.e., over .x the me-

3For eac h phase, we t a linear regression model for task lifetime

given the size of input and t he volume of trac moved across low

bandwidth links. When the residual error for a task is less than ,

i.e., its run time is within [., .]x of the time predicted by this model,

we call it explainable.

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 0.1 0.2 0.3 0.4 0.5

Cumulative Fraction of Phases

Fraction of Outliers

high runtime

recompute

(a) What fraction of tasks in a

phase are outliers?

0.2

0.4

0.6

0.8

0 1 2 4 6 8 10

Cumulative

Ratio of Straggler Duration to the

Duration of the Median Task

high runtime

recompute

(b) How much longer do out-

liers take to nish?

Figure : Prevalence of Outliers.

dian task) are well explained by the amount of data they

process or move on the network. Duplicating these tasks

would not make them run faster and will waste resources.

At the other extreme, in  of the phases (bottom le),

none of the high runtime tasks are explained by the data

they process. Figure

(b) shows tasks that take longer

than they should, as predicted by the model, but do not

take over .x the median task in their phase. Such tasks

present an opportunity for improvement. ey may n-

ish faster if run elsew here, yet current schemes do nothing

for them.  of the phases (on the top right) have over

 of such improvable tasks.

Data Skew: It is natural to ask why data size varies across

tasks in a phase. Across phases, the coecient of vari-

ation (

stdev

mean

) in data size is . and . at the 

and



percentiles. From experience, dividing work evenly

is non-trivial for a few reasons. First, scheduling each ad-

ditional task has overhead at the job manager. Network

bandwidth is another reason. ere might be too much

data on a machine for a task to process, but it may be

worse to split the work into multiple tasks and move data

over the networ k. A third reason is poor coding practice.

If the data is partitioned on a key space that has too little

entropy, i.e., a few keys correspond to a lot of data, then

the partitions will dier in size. Some reduce tasks are not

amenable to splitting (neither commutative nor associa-

tive [

]), and hence each partition has to be processed by

one task. Some joins and sorts are similarly constrained.

Duplicating tasks that run for long because they have a lot

of work to do is counter-productive.

Crossrack Trac: Reduce phases contribute over 

of the cross rack trac in the cluster, while most of the

rest is due to joins. We focus on cross rack trac because

the links upstream of the racks have less bandwidth than

the cumulative capacity of servers in the rack.

We nd that crossrack trac leads to outliers in two

ways. First, in phases where moving data across racks is

avoidable (through locality constraints), a task that ends

up in a disadvantageous network location runs slower

than others. Second, in phases where moving data across

racks is unavoidable, not accounting for the competition

among tasks within the phase (self-interference) leads to

outliers. In a reduce phase, for example, each task reads

0.2

0.4

0.6

0.8

Cumulative #Phases

0.2

0 20 40 60 80 100

Cumulative #Phases

% of tasks that have high

runtime but are explainable

(a)

0.2

0.4

0.6

0.8

Cumulative #Phases

0.2

0 20 40 60 80 100

Cumulative #Phases

% of tasks that are unexplainably

long, but not long per

(b)

Figure : Contribution of data size to task runtime (see §

.)

100

CDF % Phase

Time

0 20 40 60 80 100

CDF % Phase

Ideal Redn. (%) in Completion Time

(62.8%)

Figure : For reduce phases, the reduction in comple-

tion time over the current placement by placing tasks in a

network-aware fashion.

100

1.2

1.3

1.4

CPU Ratio

Memory Ratio

#Recomputes

Recomp

Util to Avg

Cumulative

1.1

0 10 20 30

Fraction of Cluster (%)

#Recomputes

Recomp

Cumulative

Figure : e ratio of processor and memor y usage when

recomputations happen to the average at that machine (y).

Also, t h e cumulative percentage of recomputations a cross ma-

chines (y).

from every map task. Since the maps are spread across the

cluster, regardless of where a reduce task is placed, it will

read a lot of data from other racks. Current implementa-

tions place reduce tasks on any machine with spare slots.

A r ack that has too many reduce tasks will be congested

on its downlink leading to outliers.

Figure

 compares the current placement with an ideal

one that minimizes the impact of network transfer. When

possible it avoids reading data across racks and if not,

places tasks such that their competition for bandwidth

does not result in hotspots. In over  of the jobs, reduce

phases account for  of the job’s lifetime. For the re-

duce phases, the gure shows that the median phase takes

 longer under the c urrent placement.

Bad and Busy Machines: We rarely nd machines that

persistently inate runtimes. Recomputations, however,

are more localized. Half of them happen on  of the ma-

chines in the cluster. Figure

 plots the cumulative share

of recomputes across machines on the axes on the right.

e gure also plots the ratio of processor and memory

utilization during recomputes to the overall average on

that machine. e occ urrence of recomputes is correlated

100

150

200

250

300

0 200 400 600 800 1000

Time~(minutes)

Machine Id

model outliers recomputes

Figure : C lustering recomputations and outliers.

with increased use of resources by at least . e sub-

set of machines that triggers most of the recomputes is

steady over days but varies over weeks, likely indicative

of changing hotspots in data popularity or corruption in

disks [

].

Figure  investigates the occurrence of “spikes” in out-

liers. For legibility, we only plot a subset of the machines.

We nd that runtime outliers (shown as stars) cluster by

time. If outliers were happening at random, there should

not be any horizontal bands. Rather it appears that jobs

contend for resources at some times. Even at these busy

times, other lightly loaded machines exist. Recomputa-

tions (shown as circles) cluster by machine. When a ma-

chine loses the output of a task, it has a higher chance of

losing the output of other tasks.

Rarely does an entire rack of servers experience the

same anomaly. When an anomaly happens, the frac-

tion of other machines within the rack that see the same

anomaly is less than

for recomputes, and

for run-

time with high probability. So, it is possible to restart a

task, or replicate output to protect against loss on another

machine within the same rack as the original machine.

. Impact of Outliers

We now examine the impact of outliers on job comple-

tion times and cluster usage. Figure

 plots the CDF for

the ratio of job completion times, with dierent types of

outliers included, to an ideal execution that neither has

skewed run times nor loses intermediate data. e y- axes

weighs each job by the total cluster time its tasks take to

run. e hypothetical scenarios, with some combination

of outliers present but not the others, do not exist in prac-

tice. So we replayed the logs in a trace driven simulator

that retains the structure of the job, the observed task du-

rations and the probabilities of the various anomalies (de-

tails in §). e gure shows that at median, the job com-

pletion time would be lower by  if runtime outliers

did not happen, and by more than  when none of the

outliers happen. Recomputations impact fewer jobs than

runtime outliers, but when they do, they delay comple-

tion time by a larger amount.

评论收藏

内容反馈

YYLAPPLE

2012-09-12

非常好论文集，资源有点贵，PS可以给大家伙这些论文的下载地址链接么。
xuanyuanhanxing

2012-11-07

世界顶级会议论文质量就是好，楼主整理的也非常不错，分类很详细，感谢楼主
wuwuinbnu

2012-04-14

楼主的分类很仔细，非常感谢～学习～
誓言完美

2012-09-30

分门别类，整理的很好，好评~
smilews12

2013-03-24

学习操作系统很好的资料

前往

页

蛐蛐蛐

粉丝: 774
资源: 65

USENIX OSDI 2010年论文集（Proceedings of USENIX OSDI 2010）

最新资源

USENIX OSDI 2010年论文集（Proceedings of USENIX OSDI 2010）

USENIX OSDI 2014年论文集（Proceedings of USENIX OSDI 2014）

USENIX OSDI 2008年论文集（Proceedings of USENIX OSDI 2008）

USENIX Security Symposium 2010年论文集（Proceedings of USENIX Security Symposium 2010）

USENIX Security Symposium 2009年论文集（USENIX Security 2009）

NDSS Symposium 2010论文集（Proceedings of NDSS Symposium 2010）

IEEE Symposium on Security & Privacy 2010年论文集（Proceedings of IEEE Symposium on Security & Privacy 2010）

LegoOS：用于硬件资源分解的分布式分布式OS。 USENIX OSDI 2018最佳论文

SS 2012-USENIX Security Symposium 2012年论文集

SS 2013-USENIX Security Symposium 2013年论文集

SS 2011-USENIX Security Symposium 2011年论文集

USENIX Association Proceedings of MobiSys 2003

USENIX顶会2005到2018年论文集以及论文题目摘要作者信息统计表格 part2

USENIX Security 2019论文集.pdf

OSDI 2012-Operating Systems Design and Implementation 2012年论文集

课题组成员论文集

OSDI 2010论文集

机器学习论文集

USENIX2020论文

OSDI 2010论文

计算机英语原版论文集

Proceedings of the 22nd USENIX Security Symposium (2013)

有关故障诊断专家系统的论文集

2018安全顶会usenix论文集

USENIX2019.zip

usenix security 2016 论文集

Usenix2012年论文合集

云计算硕博论文合辑-10

usenix 09 会议论文全部

计算机类顶级国际会议的论文索引

最新资源