On 28/03/2019 09:04, Jan Beulich wrote: >>>> On 28.03.19 at 08:53, <jgr...@suse.com> wrote: >> On 28/03/2019 08:46, Jan Beulich wrote: >>>>>> On 18.03.19 at 14:11, <jgr...@suse.com> wrote: >>>> Instead of freeing percpu areas during suspend and allocating them >>>> again when resuming keep them. Only free an area in case a cpu didn't >>>> come up again when resuming. >>> >>> There's another aspect here which needs at least mentioning: >>> Right now, CPUs coming back up have their per-CPU data >>> cleared. Not doing so may indeed be an improvement in >>> some cases (like statistics collected), but may also get in the >>> way in other cases. >> >> I have checked the respective cpu notifier hooks and I think this is no >> problem. I hope I didn't overlook something. > > Is checking the hooks sufficient? I'd rather expect we need to > check all per-CPU data objects.
Why? The main concern would be a hook not doing its job due to some data not being zeroed. In case there is a dependency somewhere else I'd rather expect subtle negative effects with today's solution as suddenly percpu data will be zero after suspend/resume without a component having been involved with suspending. Sure, there could be negative effects with my series, but I'd asset the chances lower as without my series. Suspend/resume tends to be not tested very often, it seems. I guess I'm the only one having it tried recently (it was broken for 3 months at least before my patch repairing an issue with IOMMU). Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
