Quoting Douglas Anderson (2020-04-13 10:04:10) > The "cmd_cache" in RPMH wasn't terribly sensible. Specifically: > > - The current code doesn't realy detect "conflicts" properly any case s/realy/really/ > where the sequence being checked has more than one entry. One > simple way to see this in the current code is that if cmd[0].addr > isn't found that cmd[1].addr is never checked. s/that/then/ ? > - The code attempted to use the "cmd_cache" to update an existing > message in a sleep/wake TCS with new data. The goal appeared to be > to update part of a TCS while leaving the rest of the TCS alone. We > never actually do this. We always fully invalidate and re-write > everything. > - If/when we try to optimize things to not fully invalidate / re-write > every time we update the TCSes we'll need to think it through very > carefully. Specifically requirement of find_match() that the new > sequence of addrs must match exactly the old sequence of addrs seems > inflexible. It's also not documented in rpmh_write() and > rpmh_write_batch(). In any case, if we do decide to require updates > to keep the exact same sequence and length then presumably the API > and data structures should be updated to understand groups more > properly. The current algorithm doesn't really keep track of the > length of the old sequence and there are several boundary-condition > bugs because of that. Said another way: if we decide to do > something like this in the future we should start from scratch and > thus find_match() isn't useful to keep around. > > This patch isn't quite a no-op. Specifically: > > - It should be a slight performance boost of not searching through so > many arrays. > - The old code would have done something useful in one case: it would > allow someone calling rpmh_write() to override the data that came > from rpmh_write_batch(). I don't believe that actually happens in > reality. > > Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx> > Reviewed-by: Maulik Shah <mkshah@xxxxxxxxxxxxxx> > Tested-by: Maulik Shah <mkshah@xxxxxxxxxxxxxx> > --- Reviewed-by: Stephen Boyd <swboyd@xxxxxxxxxxxx>
