Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Orathai Sukwong

dblp:71/9447 · DBLP profile ↗
← Back
3ranked-venue papers
3as first author
0since 2021 · last 2013
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Computer networks · 2 · 2 first-authorSystems, architecture and hardware · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer architecture, parallel and distributed computing, and storage systems
3 papers
Cloud and datacenter computing · 73% Storage systems · 27%
Software engineering, system software, and programming languages
1 paper
Operating systems · 77% Concurrent programming · 23%

Topics — the 5 heaviest of 6, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Cloud and datacenter computing
virtualization
0.432013
DPack: Disk scheduler for highly consolidated cloud · INFOCOM 2013
SageShift: Managing SLAs for highly consolidated cloud · INFOCOM 2012
Is co-scheduling too expensive for SMP VMs? · EuroSys 2011
Storage systems › i/o scheduling
disk scheduling
0.212013
DPack: Disk scheduler for highly consolidated cloud · INFOCOM 2013
Cloud and datacenter computing › virtualization › virtual machine management
virtual machine scheduling
0.112012
SageShift: Managing SLAs for highly consolidated cloud · INFOCOM 2012
Operating systems › resource management › process management
CPU scheduling
0.112011
Is co-scheduling too expensive for SMP VMs? · EuroSys 2011
Storage systems
storage reliability
0.012013
DPack: Disk scheduler for highly consolidated cloud · INFOCOM 2013

Methods — techniques the papers use, named apart from their topics

workload prediction · 0.2adaptive scheduling · 0.2hypervisor scheduling · 0.1admission control · 0.1
YearPublicationVenuePosition
2013 DPack: Disk scheduler for highly consolidated cloud
abstract
Virtualization allows us to consolidate multiple servers onto a single physical machine, saving infrastructure cost. Yet, consolidation can lead to performance degradation, jeopardizing Service Level Agreement (SLA). In this paper, we analyze and identify the factors to the performance degradation due to consolidation - that is the wait time and the ready time. The wait time is the queuing time caused by other virtual machines (VMs). The ready time is the time the resource takes to be ready to service, such as the seek time incurred in traditional storage. The ready time can substantially deteriorate the request response time. Unfortunately, existing schedulers can only manage the wait time, but not the ready time. To control both quantities, we propose an adaptive disk scheduler called DPack. DPack schedules the VMs based on the likelihood of the VM failing the SLAs. DPack then adjusts the exclusive access time based on the VM resource access prediction. DPack considers the workload changes and request arrival to enhance robustness. We develop DPack based on the default disk scheduler in KVM and evaluate it against several existing disk schedulers available in KVM and Xen. The results show that DPack can improve the 99th percentile response time up to 76%. In the highly consolidated environment, DPack can also satisfy all the SLAs, while the other schedulers cannot meet the SLAs for at least 50% of the VMs.
Orathai Sukwong, Hyong S. Kim 0001
INFOCOM1
2012 SageShift: Managing SLAs for highly consolidated cloud
abstract
Maximizing consolidation ratio, the number of virtual machines (VMs) in a physical machine, without violating customers' SLAs is an important goal in the cloud. We show that it is difficult to achieve this goal with existing hypervisor schedulers. The schedulers control only the amount of resource allocation, but not the sequence of VM execution. This sequence can significantly impact the response time when requests arrive concurrently for the VMs sharing the same CPU. We find that the response time can increase as much as 100% for every additional VM in the system, even if the utilization does not exceed the maximum capacity. Therefore, existing schedulers have to reduce the consolidation ratio to meet SLAs. Previous resource-provisioning works rely on existing schedulers that cannot guarantee SLAs without reducing the consolidation ratio. We propose SageShift, a system that can achieve SLAs without penalizing the consolidation ratio. SageShift consists of a VM admission control - Sage, and a hypervisor scheduler - Shift. To admit a VM, Sage assesses feasibility of its SLA based on the patterns of incoming requests. Shift maintains the admitted SLAs by adjusting both the amount of resource allocation and the sequence of VM execution. The dynamic adjustment is based on the observed response time and the SLAs. We modify the KVM scheduler in Linux kernel to implement Shift. We show that Shift can improve the consolidation ratio by 66% without compromising the SLAs. Under bursty incoming requests, Shift maintains all SLAs within 3% of the percentile target. But existing schedulers in VMware ESXi, Xen and KVM fail to meet one or more SLAs with up to 33% below the percentile target. Shift is also work-conserving. It allows best-effort VMs to run in the background in order to maximize hardware utilization without impacting SLAs.
Orathai Sukwong, Akkarit Sangpetch, Hyong S. Kim 0001
INFOCOM1
2011 Is co-scheduling too expensive for SMP VMs?
abstract
Symmetric multiprocessing (SMP) virtual machines (VMs) allow users to take advantage of a multiprocessor infrastructure. Despite the advantage, SMP VMs can cause synchronization latency to increase significantly, depending on task scheduling. In this paper, we show that even if a SMP VM runs non-concurrent applications, the synchronization latency problem can still occur due to synchronization in the VM kernel.
Orathai Sukwong, Hyong S. Kim 0001
EuroSys1