cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5549) Remove Table.switchLock
Date Sat, 25 Jan 2014 02:48:44 GMT


Benedict commented on CASSANDRA-5549:

bq. I think what I'm having a hard time with is, Pool should be a reservoir that we allocate
out of and instead it's a container of two such reservoirs (MT)

I can see your criticism of Pool being in fact two pools, but I think it can also be viewed
as just one. It only ever allocates one kind of resource, but in some cases those resources
may occupy memory both on and off heap. The confusing thing, perhaps, is that we overload
the trackers/owners to track not only what the pool itself is using, but also what overheads
we incur in using the pool from Memtable. This is a bit unclean conceptually, but much cleaner
in implementation.

I also think that renaming MT to Pool would be confusing. Certainly an OffHeapPool will legitimately
_pool_ (and cache) the resources it allocates, so it could get confusing if we call the thing
logging the amount the pool, and the thing actually pooling something else. MemoryOwner ->
Allocator I'm very much a -1 on, as it really doesn't allocate anything.

That said, I can see where you're coming from. Only, I have already introduced AllocatorGroup
into my follow on patch, which I think probably makes LinkedAllocatorsGroup pretty confusing

I want to offer some alternatives, but I can't think of anything better.

MemoryTracker -> Ledger?
MemoryOwner -> Account? 

Pool -> Reservoir works for me

> Remove Table.switchLock
> -----------------------
>                 Key: CASSANDRA-5549
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jonathan Ellis
>            Assignee: Benedict
>              Labels: performance
>             Fix For: 2.1
>         Attachments: 5549-removed-switchlock.png, 5549-sunnyvale.png
> As discussed in CASSANDRA-5422, Table.switchLock is a bottleneck on the write path. 
ReentrantReadWriteLock is not lightweight, even if there is no contention per se between readers
and writers of the lock (in Cassandra, memtable updates and switches).

This message was sent by Atlassian JIRA

View raw message