[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 2/2] almost fully ignore zero-size flush requests
On Tue, Feb 20, 2024 at 4:26 PM Jan Beulich <jbeulich@xxxxxxxx> wrote: > >> + if ( (cflush->offset | cflush->length) > PAGE_SIZE || > > > > This is confusing. I understand you are trying to force the compiler to > > optimize. But is it really worth it? After all, the rest of operation > > will outweight this check (cache flush are quite expensive). > > From purely a performance point of view it may not be worth it. From > code size angle (taken globally) I already view this differently. > Plus I think that we ought to aim at avoiding undesirable patterns, > just because people tend to clone existing code when they can. Thing > is that (as per below) the two of us apparently disagree on what > "undesirable" is in cases like this one. > > > We probably should take a more generic decision (and encode in our > > policy) because you seem to like this pattern and I dislike it :). Not > > sure what the others think. This is similar to the policy question I raised among the x86 committers a few weeks ago: You're manually specifying a more specific behavior than is required, rather than specifying what you want and then letting the compiler optimize things. The problem with this is twofold: 1. It's harder for humans to read and understand the intent 2. It ties the compiler's hands. If you write your intent, then the compiler is free to apply the optimization or not, or apply a different optimization. If you specify this optimization, then the compiler has fewer ways that it's allowed to compile the code. #1 by itself is probably enough to counterindicate this kind of behavior. Add them together, and I'm inclined to say that we should write a policy against such optimizations, without specific justifications. -George
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |