glusterfs.git/libglusterfs/src/syncop.c, branch v3.11.3

cluster/dht: rebalance perf enhancement

2017-04-29T14:28:19+00:00

Problem: Throttle settings "normal" and "aggressive" for rebalance
did not have performance difference.

normal mode spawns $(no. of cores - 4)/2 threads and aggressive
spawns $(no. of cores - 4) threads. Though aggressive mode has twice
the number of threads compared to that of normal mode, there was no
performance gain when switched to aggressive mode from normal mode.

RCA:
During the course of debugging the above problem, we tried assigning
migration job to migration threads spawned by rebalance, rather than
synctasks(as there is more overhead associated to manage the task
queue and threads). This gave us a significant improvement over rebalance
under synctasks. This patch does not really gurantee that there will be a
clear performance difference between normal and aggressive mode, but this
patch certainly maximized the disk utilization for 1GBfiles run.

Results:

Test enviroment:
Gluster Config:
Number of Bricks: 2 (one brick per disk(RAID-6 12 disk))
Bricks:
Brick1: server1:/brick/test1/1
Brick2: server2:/brick/test1/1
Options Reconfigured:
performance.readdir-ahead: on
server.event-threads: 4
client.event-threads: 4

1000 files with 1GB each were created/renamed such that all files will have
server1 as cached and server2 as hashed, so that all files will be migrated.

Test machines had 24 cores each.

Results  with/without synctask based migration:
-----------------------------------------------

mode                    normal(10threads)          aggressive(20threads)

timetaken               0:55:30 (h:m:s)            0:56:3 (h:m:s)
withsynctask

timetaken
with migrator           0:38:3 (h:m:s)             0:23:41 (h:m:s)
threads

From above table it can be seen that, there is a clear 2x perf gain between
rebalance with synctask vs rebalance with migrator threads.

Additionally this patch modifies the code so that caller will have the exact error
number returned by dht_migrate_file(earlier the errno meaning was overloaded). This
will help avoiding scenarios where migration failure due to ENOENT, can result in
rebalance abort/failure.

Change-Id: I8904e2fb147419d4a51c1267be11a08ffd52168e
BUG: 1420166
Signed-off-by: Susant Palai 
Reviewed-on: https://review.gluster.org/16427
Smoke: Gluster Build System 
Reviewed-by: N Balachandran 
Reviewed-by: Raghavendra G 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

syncop: don't wake task in synctask_wake unless really needed

2017-03-28T22:34:48+00:00

Problem:

In EC and AFR, we launch synctasks during self-heal.

(i) These tasks usually stackwind a FOP to all its children and call
synctask_yield() which does a swapcontext to synctask_switchto() and puts the
task in syncenv's waitq by calling __wait(task). This happends as long as the
FOP ckbs from all children haven't been received.

(ii) For each FOP cbk, we call synctask_wake() which again does a swapcontext
to synctask_switchto() which now puts the task in syncenv's runq by calling
__run(task). When the task runs and the conext switches back to the FOP path,
it puts the task in waitq because we haven't heard from all children as
explained in (i).

Thus we are unnecessarily using the swapcontext syscalls to just toggle
the task back and forth between the waitq and runq.

Fix:
Store the stackwind count in new variable 'syncbarrier->waitfor' before
winding the fop. In each cbk when we call synctask_wake(),  perform an actual
wake only if the cbk count == stackwind count.

Change-Id: Id62d3b6ffed5a8c50f8b79267fb34e9470ba5ed5
BUG: 1434274
Signed-off-by: Ravishankar N 
Signed-off-by: Ashish Pandey 
Reviewed-on: https://review.gluster.org/16931
Smoke: Gluster Build System 
Reviewed-by: Niels de Vos 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri

syncop: Fix args for makecontext

2017-03-28T05:55:41+00:00

Passing 64bit arguments to makecontext is not portable and manpage says the following:


On  architectures where int and pointer types are the same size (e.g., x86-32, where
both types are 32 bits), you may be able to get away with passing pointers as  argu‐
ments  to makecontext() following argc.  However, doing this is not guaranteed to be
portable, is undefined according to the standards, and won't work  on  architectures
where pointers are larger than ints.  Nevertheless, starting with version 2.8, glibc
makes some changes to makecontext(), to permit this  on  some  64-bit  architectures
(e.g., x86-64).


Since we do not depend on the arguments, it is better to change makecontext to not
take any arguments.

BUG: 1434274
Change-Id: Ic46c9e9faaeb2f78e4efde353ef861466515b1ec
Signed-off-by: Pranith Kumar K 
Reviewed-on: https://review.gluster.org/16951
Smoke: Gluster Build System 
Reviewed-by: Ravishankar N 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System

core: fix synclocks' handling of "woken" flag

2017-03-23T12:45:23+00:00

The "woken" flag wasn't being reset when it should have been, leading
(eventually) to a SEGV when someone tried to folow a synclock's waitq
to a task structure that had been freed while still on the queue.  See
the bug report for (far) more detail.

Change-Id: I5cd9ae1bcb831555274108b292181ec2a29b6d95
BUG: 1434062
Signed-off-by: Jeff Darcy 
Reviewed-on: https://review.gluster.org/16926
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Smoke: Gluster Build System 
Reviewed-by: Amar Tumballi

syncop: fix argc count in call to makecontext()

2017-03-21T13:18:22+00:00

We are only passing one argument (a pointer to struct synctask) to the
function, so argc must be 1 and not 2.

Change-Id: I4eaadd58a76f32327d8bb3efa9c5c435700d7391
BUG: 1434274
Signed-off-by: Ravishankar N 
Reviewed-on: https://review.gluster.org/16930
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Jeff Darcy

libglusterfs, dht, locks, glusterd: Coverity fixes

2017-02-23T12:14:33+00:00

Fix up use after free bugs and dead code

Change-Id: I8f79ed6b5108926c1fac31c147b5ecba79d10785
BUG: 1424905
Signed-off-by: Nigel Babu 
Reviewed-on: https://review.gluster.org/16666
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Atin Mukherjee 
Reviewed-by: Shyamsundar Ranganathan

core: Honour mandatory lock flags during lock migration

2016-05-20T11:23:19+00:00

lk_flags from posix_lock_t structure is the primary key used to
differentiate locks as either advisory and mandatory type. During
lock migration this field is not read in getactivelk() call path.
So in order to copy the exact lock state from source to destination
it is necessary to include lk_flags within lock_migration_info_t
structure to maintain accurate state. This change also includes
minor modifications to setactivelk() call to consider lk_flags
during lock migration.

Change-Id: I20a7b6b6a0f3bdac5734cce8a2cd2349eceff195
BUG: 1332501
Signed-off-by: Anoop C S 
Reviewed-on: http://review.gluster.org/14189
Smoke: Gluster Build System 
Reviewed-by: Susant Palai 
Reviewed-by: Poornima G 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri

core: add setactivelk () fop

2016-05-02T01:04:42+00:00

Change-Id: Ic2ba77a1fdd27801a6e579e04e6c0dd93cd7127b
BUG: 1326085
Signed-off-by: Susant Palai 
Reviewed-on: http://review.gluster.org/14011
Reviewed-by: Niels de Vos 
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

core: add getactivelk () fop

2016-05-02T01:04:21+00:00

Change-Id: Ifd0ff278dcf43da064021f5c25e5dcd34347fcde
BUG: 1326085
Signed-off-by: Susant Palai 
Reviewed-on: http://review.gluster.org/13970
Smoke: Gluster Build System 
Reviewed-by: Niels de Vos 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

Use pthread_equal to compare threads

2016-04-25T16:43:37+00:00

The man pages about pthreads are quite clear on the fact that pthread_t
is supposed to be opaque, and so can't be compared using the equality
operator.

Change-Id: Id69e166ed73a98668d19a71cd6d9ab9a0429ec38
BUG: 1330225
Signed-off-by: Michael Scherer