Re: [Gluster-devel] Multiplexing - good news, bad news, and a plea for help

> If I understood brick-multiplexing correctly, add-brick/remove-brick > add/remove graphs right? I don't think the grah-cleanup is in good > shape, i.e. it should lead to memory leaks etc. Did you get a chance > to think about it? I haven't tried to address memory leaks specifically, but most of

Re: [Gluster-devel] Multiplexing - good news, bad news, and a plea for help

> That's weird, since the only purpose of the mem-pool was precisely to > improve performance of allocation of objects that are frequently > allocated/released. Very true, and I've long been an advocate of this approach. Unfortunately, for this to work our allocator has to be more efficient than

Re: [Gluster-devel] Multiplexing - good news, bad news, and a plea for help

Jeff, If I understood brick-multiplexing correctly, add-brick/remove-brick add/remove graphs right? I don't think the grah-cleanup is in good shape, i.e. it should lead to memory leaks etc. Did you get a chance to think about it? On Mon, Sep 19, 2016 at 6:56 PM, Jeff Darcy

Re: [Gluster-devel] Multiplexing - good news, bad news, and a plea for help

On 19/09/16 15:26, Jeff Darcy wrote: I have brick multiplexing[1] functional to the point that it passes all basic AFR, EC, and quota tests. There are still some issues with tiering, and I wouldn't consider snapshots functional at all, but it seemed like a good point to see how well it

Re: [Gluster-devel] Multiplexing - good news, bad news, and a plea for help

- Original Message - > From: "Jeff Darcy" > To: "Gluster Devel" > Sent: Monday, September 19, 2016 6:56:39 PM > Subject: [Gluster-devel] Multiplexing - good news, bad news, and a plea for > help > > I have brick multiplexing[1]

Re: [Gluster-devel] Multiplexing - good news, bad news, and a plea for help

> I wonder if we are spending more time in io-threads. Does setting > idle-time in io-threads to 1 help with anything? > It might be useful to add instrumentation subsequently to dump > statistics (number of fops serviced, time spent in servicing) per > thread. Having the same visibility for our

Re: [Gluster-devel] Multiplexing - good news, bad news, and a plea for help

On Mon, Sep 19, 2016 at 2:20 PM, Jeff Darcy wrote: > FWIW, I did some further experiments. Disabling mem-pool entirely (in favor > of plain malloc/free) brought run time down to 3:35, vs. 2:57 for the exact > same thing without multiplexing. Somehow we're still not managing

Re: [Gluster-devel] Multiplexing - good news, bad news, and a plea for help

FWIW, I did some further experiments. Disabling mem-pool entirely (in favor of plain malloc/free) brought run time down to 3:35, vs. 2:57 for the exact same thing without multiplexing. Somehow we're still not managing contention very well at this kind of thread count, but the clues and

Re: [Gluster-devel] Multiplexing - good news, bad news, and a plea for help

On 09/19/2016 11:34 PM, Jeff Darcy wrote: I would like to collaborate in investigating the memory-management, and also bringing multiplexing to snapshots. For starters, will be going through your patch(1400+ lines of change, that's one big ass patch :p) That's nothing. I've seen 7000-line

Re: [Gluster-devel] Multiplexing - good news, bad news, and a plea for help

> I would like to collaborate in investigating the memory-management, and > also bringing multiplexing to snapshots. For starters, will be going > through your patch(1400+ lines of change, that's one big ass patch :p) That's nothing. I've seen 7000-line patches go in, without even any evidence

Re: [Gluster-devel] Multiplexing - good news, bad news, and a plea for help

On 09/19/2016 06:56 PM, Jeff Darcy wrote: I have brick multiplexing[1] functional to the point that it passes all basic AFR, EC, and quota tests. There are still some issues with tiering, and I wouldn't consider snapshots functional at all, but it seemed like a good point to see how well it