It seems like some of the confusion arises from the fact that the consumers aren't actually programmed to back off/quiesce as the polling-avoidance strategy expects. Matt On Wed, Mar 23, 2022 at 9:46 AM Yehuda Sadeh-Weinraub <yehuda@xxxxxxxxxx> wrote: > > On Tue, Mar 22, 2022 at 2:14 PM Adam C. Emerson <aemerson@xxxxxxxxxx> wrote: > > > > On 22/03/2022, Matt Benjamin wrote: > > > Just to be clear, why do we think it doesn't serve as an optimization? > > > > My thought being, if we're already saturated with syncing stuff, > > adding more work on top of it won't help anything. > > And what if we're not saturated? You're optimizing the high traffic > case by killing the low traffic case. If there are specific > implementation issues then address them, but I think this is very > valuable to some use cases. > > Yehuda > > > > > > OTOH, as Yehuda points out, the intended purpose of the async > > > notifies was to implement polling avoidance--to provide wake-ups to > > > sync endpoints that might otherwise sleep/idle as replication events > > > accumulate. This is a well established design pattern, and if we > > > remember that the async notifies are duplicating hints, it seems to > > > make sense. > > > > Measuring to see how consequential this is would be legitimate. > > > > I can imagine a world where if the primary has an idea what the > > secondary's polling period is, and there hasn't been much sync > > activity and the primary knows the secondary won't poll for a while, > > it might be worthwhile to send a single wakeup event when there's new > > data available telling it that there's new stuff in the data log. > > > > Whether this is worthwhile would depend heavily on how frequently the > > secondary polls the data log in the first place. > > > > _______________________________________________ > > Dev mailing list -- dev@xxxxxxx > > To unsubscribe send an email to dev-leave@xxxxxxx > > > > _______________________________________________ > Dev mailing list -- dev@xxxxxxx > To unsubscribe send an email to dev-leave@xxxxxxx > -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309 _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
