Hi, On Wed, Oct 4, 2023 at 1:28 PM Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > No one really seemed all that interested in it. I'd still like to get > it in, if for no other reason than to make things operate more uniformly. > Though there are lots of legacy codepaths left that still hold the locks > over the whole commit, but those could be fixed up as a followup.
Ah I see what you're saying. > > > execpt I went further and moved the flush past the unlock in the end. > > > > Is that necessary? I was wondering about that but there's this comment > > in the code: > > I'm not really sure there is any point in doing this otherwise. > It would just change which thread executes the code but everything > else would still get blocked on the locks the same as before. Well in my case, I just want driver work to not charge the process cpu time. But I get what you're saying, Checking if new configurations are valid shouldnt block on existing configurations getting applied. Doing it outside the locks isn't necessary to prevents deadlocks, it's necessary because you're trying to avoid contention when there doesn't need to be contention. Your patchset sort of has a different goal, but it solves the issue I care about at the same time. I'd be happy if it went in... Daniel, Dave, what are your takes on this? --Ray
