cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-8897) Remove FileCacheService, instead pooling the buffers
Date Wed, 22 Apr 2015 13:21:00 GMT

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

Benedict edited comment on CASSANDRA-8897 at 4/22/15 1:20 PM:
--------------------------------------------------------------

bq. To to ensure we detect when the chunk is fully free, isFree() is no longer very cheap
since the ordinary count must become volatile, and the atomic count must also be read (and
its value is also a volatile int). So I think you meant to keep isFree() extremely cheap and
check in some other place? Still, the ordinary count would have to be volatile surely?

A volatile read is pretty much free in this context on any platforms we are likely running
on. However we can avoid this problem and the atomic boolean issue, by overloading the atomic
free count's meaning: if we increment it by one using cas when our combined count is equal
to the free count, then we can ensure only one thread takes ownership of the action of returning
the chunk (i.e. the on that incremented it by one). The normal free count does not need to
be volatile (which would make _writes_ expensive), because the other thread can piggy-back
on its own free count variable's volatile status to perform a volatile read of the normal
count (and the normal thread does not need to access it with volatile semantics)

I would prefer we use AtomicIntegerFieldUpdater than AtomicInteger, so we can keep the overhead
of this class down.

bq. For the rest, we basically attach a thread id to the chunk to determine which thread owns
it, if any, and we attach the chunk to the buffers as you suggested.

Why not just attach the LocalPool object itself? (technically we could have the same id reused,
but not a major risk. But it is probably cleaner to just use the LocalPool anyway)

bq. but as it turns out we need to unpack the position before sorting so we could change it
to an array of 24 shorts rather than 12 ints

Well, since we know the size of the buffer has to be <= 32Kb, we can safely encode both
size and position in the lower 31 bits of the int, with the position occurring in the upper
16 bits, at which point we can safely sort the ints.

However we can go further: if we impose a lower limit of, say, 64 bytes on the size of the
allocated buffer (rounding up if smaller) then since we operate on powers of 2, we have only
10 possible values to encode (11 if you include 64Kb). We also have only {{2^16 / 2^6 = 2^10}}
positions to encode, So we need 10 bits for the position, and only 4 bits for the size, which
can all fit in the positive component of a single short.

Of course, we probably need to impose a lower bound of 4K to ensure page alignment for >
4Kb buffers, or when allocating across a page boundary we need to realign ourselves and "free"
the buffers we don't allocate, by logging them in this list


was (Author: benedict):
bq. To to ensure we detect when the chunk is fully free, isFree() is no longer very cheap
since the ordinary count must become volatile, and the atomic count must also be read (and
its value is also a volatile int). So I think you meant to keep isFree() extremely cheap and
check in some other place? Still, the ordinary count would have to be volatile surely?

A volatile read is pretty much free in this context on any platforms we are likely running
on. However we can avoid this problem and the atomic boolean issue, by overloading the atomic
free count's meaning: if we increment it by one using cas when our combined count is equal
to the free count, then we can ensure only one thread takes ownership of the action of returning
the chunk (i.e. the on that incremented it by one). The normal free count does not need to
be volatile, because the other thread can piggy-back on its own free count variable's volatile
status to perform a volatile read of the normal count (and the normal thread does not need
to access it with volatile semantics)

I would prefer we use AtomicIntegerFieldUpdater than AtomicInteger, so we can keep the overhead
of this class down.

bq. For the rest, we basically attach a thread id to the chunk to determine which thread owns
it, if any, and we attach the chunk to the buffers as you suggested.

Why not just attach the LocalPool object itself? (technically we could have the same id reused,
but not a major risk. But it is probably cleaner to just use the LocalPool anyway)

bq. but as it turns out we need to unpack the position before sorting so we could change it
to an array of 24 shorts rather than 12 ints

Well, since we know the size of the buffer has to be <= 32Kb, we can safely encode both
size and position in the lower 31 bits of the int, with the position occurring in the upper
16 bits, at which point we can safely sort the ints.

However we can go further: if we impose a lower limit of, say, 64 bytes on the size of the
allocated buffer (rounding up if smaller) then since we operate on powers of 2, we have only
10 possible values to encode (11 if you include 64Kb). We also have only {{2^16 / 2^6 = 2^10}}
positions to encode, So we need 10 bits for the position, and only 4 bits for the size, which
can all fit in the positive component of a single short.

Of course, we probably need to impose a lower bound of 4K to ensure page alignment for >
4Kb buffers, or when allocating across a page boundary we need to realign ourselves and "free"
the buffers we don't allocate, by logging them in this list

> Remove FileCacheService, instead pooling the buffers
> ----------------------------------------------------
>
>                 Key: CASSANDRA-8897
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8897
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Assignee: Stefania
>             Fix For: 3.0
>
>
> After CASSANDRA-8893, a RAR will be a very lightweight object and will not need caching,
so we can eliminate this cache entirely. Instead we should have a pool of buffers that are
page-aligned.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message