Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 6 Aug 2014 16:15:13 +0000 (UTC)
From: "graham sanderson (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12727216.1405385811889.26207.1407341713533@arcas>
In-Reply-To: <JIRA.12727216.1405385811889@arcas>
References: <JIRA.12727216.1405385811889@arcas>
Subject: [jira] [Comment Edited] (CASSANDRA-7546)
 AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates
 memory
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14087841#comment-14087841 ] 

graham sanderson edited comment on CASSANDRA-7546 at 8/6/14 4:13 PM:
---------------------------------------------------------------------

Cool will do; addColumns also CASes a thread locally modified Holder anyway.

Yes I agree it is ugly to have a non final in something like Holder (being CASed immutable state) but I think we can live with it since it is not mutated after CAS

As said, we can revert to monitor enter/exit if you wish... I can't prove it is worse, and there isn't a whole lot that needs optimization here
Note you have a comment

{quote}
in wasteTracker we maintain within EXCESS_WASTE_OFFSET either side of the current time
{quote}

We probably mean "to the left" of... "before" or "after" are a bit confusing here!

I thought about a couple of things while you were on vacation

# Volatile read of the wasteTracker in the "fast" path. We could avoid this thru some ugliness of hijacking the top bit in the tree size to mark pessimistic locking also. Not to concerned about this read - believe it is free on intel anyway
# Adjacent in memory CASed vars in the AtomicSortedColumns - Again not majorly worried here... I don't think the (CASed) variables themselves are highly contended, it is more that we are doing lots of slow concurrent work, and then failing the CAS.


was (Author: graham sanderson):
Cool will do; addColumns also CASes a thread locally modified Holder anyway.

Yes I agree it is ugly to have a non final in something like Holder (being CASed immutable state) but I think we can live with it since it is not mutated after CAS

As said, we can revert to monitor enter/exit if you wish... I can't prove it is worse, and there isn't a whole lot that needs optimization here
Note you have a comment

{quote}
in wasteTracker we maintain within EXCESS_WASTE_OFFSET either side of the current time
{quote}

We probably mean "to the left" of... "before" or "after" are a bit confusing here!

I thought about a couple of things while you were on vacation

# Volatile read of the wasteTracker in the "fast" path. We could avoid this thru some ugliness of hijacking the top bit in the tree size mark pessimistic locking too. Not to concerned about this - believe it is free on intel anyway
# Adjacent in memory CASed vars in the AtomicSortedColumns - Again not majorly worried here... I don't think the (CASed) variables themselves are highly contended, it is more that we are doing lots of slow concurrent work, and then failing the CAS.


> AtomicSortedColumns.addAllWithSizeDelta has a spin loop that allocates memory
> -----------------------------------------------------------------------------
>
>                 Key: CASSANDRA-7546
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7546
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: graham sanderson
>            Assignee: graham sanderson
>         Attachments: 7546.20.txt, 7546.20_2.txt, 7546.20_3.txt, 7546.20_4.txt, 7546.20_5.txt, 7546.20_6.txt, 7546.20_alt.txt, suggestion1.txt, suggestion1_21.txt
>
>
> In order to preserve atomicity, this code attempts to read, clone/update, then CAS the state of the partition.
> Under heavy contention for updating a single partition this can cause some fairly staggering memory growth (the more cores on your machine the worst it gets).
> Whilst many usage patterns don't do highly concurrent updates to the same partition, hinting today, does, and in this case wild (order(s) of magnitude more than expected) memory allocation rates can be seen (especially when the updates being hinted are small updates to different partitions which can happen very fast on their own) - see CASSANDRA-7545
> It would be best to eliminate/reduce/limit the spinning memory allocation whilst not slowing down the very common un-contended case.


--
This message was sent by Atlassian JIRA
(v6.2#6252)