redis-rcp
redis-rcp copied to clipboard
redis
Request for RCP number 2
Currently it looks like it would be #2. I am preparing an RCP for a memory related stat to be tracked and made available in the info command.
I am preparing an RCP for a memory related stat to be tracked and made available in the info command.
Just adding a single new field should be fine for a PR. I think RCPs are more for server-wide design issues.
There's also now DEBUG JEMALLOC INFO in unstable too.
It prints something like:
127.0.0.1:6379> debug jemalloc info
___ Begin jemalloc statistics ___
Version: 3.6.0-0-g46c0af68bd248b04df75e4f92d5fb804c3d75340
Assertions disabled
Run-time option settings:
opt.abort: false
opt.lg_chunk: 22
opt.dss: "secondary"
opt.narenas: 16
opt.lg_dirty_mult: 3
opt.stats_print: false
opt.junk: false
opt.quarantine: 0
opt.redzone: false
opt.zero: false
opt.valgrind: false
opt.tcache: true
opt.lg_tcache_max: 15
CPUs: 4
Arenas: 16
Pointer size: 8
Quantum size: 16
Page size: 4096
Min active:dirty page ratio per arena: 8:1
Maximum thread-cached size class: 32768
Chunk size: 4194304 (2^22)
Allocated: 882128, active: 897024, mapped: 8388608
Current active ceiling: 4194304
chunks: nchunks highchunks curchunks
2 2 2
huge: nmalloc ndalloc allocated
0 0 0
arenas[0]:
assigned threads: 1
dss allocation precedence: disabled
dirty pages: 219:0 active:dirty, 0 sweeps, 0 madvises, 0 purged
allocated nmalloc ndalloc nrequests
small: 529872 11928 74 10805
large: 352256 10 2 10
total: 882128 11938 76 10815
active: 897024
mapped: 4194304
bins: bin size regs pgs allocated nmalloc ndalloc nrequests nfills nflushes newruns reruns curruns
0 8 501 1 208 100 74 2 1 1 1 0 1
1 16 252 1 166400 10400 0 10316 104 0 42 0 42
2 32 126 1 16000 500 0 403 5 0 4 0 4
3 48 84 1 4032 84 0 0 1 0 1 0 1
4 64 63 1 4032 63 0 0 1 0 1 0 1
5 80 50 1 4000 50 0 0 1 0 1 0 1
6 96 84 2 16128 168 0 84 2 0 2 0 2
7 112 72 2 8064 72 0 0 1 0 1 0 1
8 128 63 2 8064 63 0 0 1 0 1 0 1
9 160 51 2 8160 51 0 0 1 0 1 0 1
[10]
11 224 72 4 16128 72 0 0 1 0 1 0 1
12 256 63 4 16128 63 0 0 1 0 1 0 1
[13..15]
16 512 63 8 32256 63 0 0 1 0 1 0 1
17 640 51 8 32640 51 0 0 1 0 1 0 1
[18..19]
20 1024 63 16 64512 63 0 0 1 0 1 0 1
[21..23]
24 2048 65 33 133120 65 0 0 1 0 1 0 1
[25..27]
large: size pages nmalloc ndalloc nrequests curruns
[3]
16384 4 1 0 1 1
20480 5 2 0 2 2
[2]
32768 8 1 0 1 1
36864 9 4 2 4 2
[3]
53248 13 1 0 1 1
[19]
135168 33 1 0 1 1
[985]
--- End jemalloc statistics ---
No need for an RCP, no huge design challenges since it's a purely technical stuff, and no API changes. Cheers.
That looks like great information to have and I look forward to it, Matt, but what I am proposing is a bit different. Please see https://github.com/TheRealBill/redis-rcp/blob/master/RCP2.md for details. I didn't figure I had to put all of the proposal in the request for a number. ;)
There is a command proposal in it. Sure from a design point of view it isn't "hard" as it mimics an existing command. However, that aside it isn't just adding a field as it has to track something I don't think Redis tracks currently in order to add it.
All that sad, @antirez I think it is a good idea to approve/reject the RCP itself as it shows people, especially potential contributors, activity and movement on "changes desired" rather than rejecting a request to get a number to make the proposal. Ot at a minimum ask for more details if you don't think there are enough in the request to get a number before closing it.
@mattsta I also think all PRs that aren't fixing bugs should have a change request as they are changes to Redis. As (IIRC) @antirez has said "PRs are not discussions". ;)
Roundup:
- quick review: the original message here basically said "I want to add a thing." Not enough details to provide any help. :)
- should all non-bug-fix PRs be RCPs instead? It's a good idea, but we don't have the time to manage everything going though such a process. That would add another 5 process steps and we don't have the people-time to manage heavy process for tiny issues. We can do heavy process for big issues, but small things are as-needed.
- the "request a number" feels a bit strange. no need to ask for permission, just provide complete ideas. Too much permission-asking is like people who call before they send an email, then they send you an email, then they call again to tell you they sent you an email. :)
- and, at least for me, PRs are discussions on specific issues, but the ML is better for general idea sharing.
@mattsta I'm just going by the process outlined in the README. ;) I says to file an issue requesting it, then create the PR and then post to the ML for discussion. I agree that the request a number feels odd but am just using the process as @antirez defined it. I would be terribly conflicting if many people were trying to use the same number so I kinda get it. It looks to me like that is the point of the step - not discussion of the proposal itself just reserving the number. Viewed that way it seems reasonable to me. As such there isn't, that I can see, a reason to put all the details in that request. Otherwise RCPs would just be issues instead of PRs and then, IMO, we'd be right back to the original problem.
If, however, it really is asking permission to write up an RCP I'd recommend correcting the README so people wanting to do that don't get/feel shut down as was done on the redis issue list.
Someone had to be the first to test the process, it just happened to be me. ;)
As far as time by making changes from those of us outside of the core contributor group I seem to recall that this is a means for people to see what is being done, what is in flight, what was rejected, etc. and that doing more than just "hey I want this" raises the quality of the request. It also makes it a tad easier to put better change details in a changeling as you can reference the list of RCPs which went into the list and link to the repo for those who want to read the details.
Regarding how much time it takes to review them here ... well this repo is how old and this is the first such request? ;)
We've spent more time here discussing the defined process I was following than I spent on following it. I was merely taken aback by @antirez not following it.
Thanks for clarifying, well if you want to present it as an RCP, it makes sense... for future reference for example, or if the proposal is refused in order to have anyway some clear archive of what happened, or if we believe we should address the same problem, to reference the new RCP with the old saying the old is deprecated, but capturing the first history.
So RCP2 assigned to your proposal.
p.s. reopening since accepted RCP numbers should have their issue always open so that other can see where we are with the numbering. Also, issue renamed to make it clear it was RCP2.