My recollection is that indeed they are non-trivial for small reads even for replicated pools. However, I don't think it's an "issue" since the lion's share of the cpu and latency consumption are elsewhere and the difference in performance over classic appears significant. Further, Kefu indicated above that they've done some testing with the classic osd modified in the same way and the advantage persists. Basically, I think getting more "realistic" numbers is isomorphic to actually implementing the full crimson IO paths. -Sam -Sam On Thu, Apr 4, 2019 at 2:12 PM Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: > > On Wed, Apr 3, 2019 at 7:19 PM Sam Just <sjust@xxxxxxxxxx> wrote: > > > > I don't think we're cheating, as such. I think the messenger and the > > ObjectStore implementation will indeed dominate the overall cpu usage > > and latency for reads in the common case for both classic and crimson, > > so the setup we've got for crimson is probably reasonable. If we're > > actually worried about it, we could probably short-circuit the classic > > osd in the same way and get numbers that way? > > Is there a description of what pieces are done in Crimson and which aren't? > I have maybe-completely-erroneous recollection that the "this object > maps to this PG, and we can work on this PG" checks are actually > pretty expensive (or at least, have been at various times in the > past), probably mostly because of the map consistency requirements? So > if we're skipping everything in that category, it may be an issue. > -Greg > > > > > Actually adding the checks (by which I mean whatever is required for > > crimson to behave like an osd, not necessarily what's in classic) is > > pretty much implementing the full read and write paths for crimson, so > > I'd guess that's where we're going anyway? > > -Sam > > > > > > On Wed, Apr 3, 2019 at 5:35 AM kefu chai <tchaikov@xxxxxxxxx> wrote: > > > > > > in today's standup meeting, we were discussing the apple-to-apple > > > comparison. i think it still matters to have a rough apple-to-apple > > > comparison to make sure we don't cut corners and hence won't be > > > over-optimistic when benchmarking crimson-osd. > > > > > > if we are "cheating" and just connecting the messenger and backend > > > store, skipping the critical factors that have significant impacts on > > > the performance in classic OSD in normal i/o patterns. our test result > > > won't be representative. > > > > > > i think one of the reasons why we implemented the read path first is > > > that it is a typical i/o operation that we can have with minimal > > > efforts. if the various checks are playing a significant role slowing > > > down OSD, then we should at least understand if they still apply in > > > crimson-osd. if yes, we should implement them, i guess. checksum > > > verification based on object-info might be one of them. probably we > > > can indeed skip this step, assuming bluestore will be dominant very > > > soon. > > > > > > > > > -- > > > Regards > > > Kefu Chai
