Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 83DF2116A2 for ; Tue, 15 Apr 2014 18:48:33 +0000 (UTC) Received: (qmail 96884 invoked by uid 500); 15 Apr 2014 18:48:19 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 96827 invoked by uid 500); 15 Apr 2014 18:48:18 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 96735 invoked by uid 99); 15 Apr 2014 18:48:17 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Apr 2014 18:48:17 +0000 Date: Tue, 15 Apr 2014 18:48:17 +0000 (UTC) From: "Benedict (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CASSANDRA-7040) Replace read/write stage with per-disk access coordination MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969882#comment-13969882 ] Benedict commented on CASSANDRA-7040: ------------------------------------- bq. I don't think that's necessarily blocked by this work Sure - and if you want to start building one right now, go to town :) I only mean that I think it builds on the work here and in 5863, as they both involve intercepting the points at which we perform disk accesses and inserting some (minimal) coordination inebetween them. Swapping those interception points for something more intelligent is probably more straightforward once we've done that, and having a cache in which to deposit the result is _probably_ helpful too (definitely none of this is 100% essential though). > Replace read/write stage with per-disk access coordination > ---------------------------------------------------------- > > Key: CASSANDRA-7040 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7040 > Project: Cassandra > Issue Type: Improvement > Components: Core > Reporter: Benedict > Labels: performance > Fix For: 3.0 > > > As discussed in CASSANDRA-6995, current coordination of access to disk is suboptimal: instead of ensuring disk accesses alone are coordinated, we instead coordinate at the level of operations that may touch the disks, ensuring only so many are proceeding at once. As such, tuning is difficult, and we incur unnecessary delays for operations that would not touch the disk(s). > Ideally we would instead simply use a shared coordination primitive to gate access to the disk when we perform a rebuffer. This work would dovetail very nicely with any work in CASSANDRA-5863, as we could prevent any blocking or context switching for data that we know to be cached. It also, as far as I can tell, obviates the need for CASSANDRA-5239. -- This message was sent by Atlassian JIRA (v6.2#6252)