Re: [tip:x86/cache 9/13] arch/x86/kernel/cpu/resctrl/rdtgroup.c:1456:6: warning: variable 'h' set but not used

[Philip Li]

On Thu, Feb 09, 2023 at 10:53:47AM +0100, Borislav Petkov wrote:
> On Thu, Feb 09, 2023 at 11:06:34AM +0800, Philip Li wrote:
> > Thanks a lot for the suggestions, we will think of this to continuously optimize the
> > service. Right now, we try to build-test the patches that we can find a suitable base
> > to apply the patches successfully, some of effort could fail. Then we only test them
> > when they appears on repo. We will keep monitoring the patch testing status to see
> > anything we can fix as well.
> 
> Cool, thanks.

Thanks a lot Boris for your time and suggestions. I add some extra information and next step
info below.

> 
> I see you've started doing silly tests like subdirectory builds for W=
> warnings, picking one such report at random from lkml:
> 
> https://lore.kernel.org/r/202302091432.VgittDjI-lkp@xxxxxxxxx
> 
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=powerpc SHELL=/bin/bash drivers/spi/

Sorry for confusion, we do full make for the kernel to gather all issues.
And we try to provide a quicker way for developer to reproduce the issue,
thus the step in reproduce part shows the subdirectories that could reproduce
the reported issue.

> 
> and then it says
> 
> drivers/spi/spi-mpc52xx-psc.c:195:5: warning: no previous prototype for 'mpc52xx_psc_spi_transfer_one_message' [-Wmissing-prototypes]
> 
> Yes, this is all fine and dandy but such tests should be the lowest prio
> eva! If you have a way to schedule by prio, those should wait until all
> the other build tests have happened.

Thanks for suggestion, we will think of how to prioritize different issues.

> 
> I don't know how your resources are spread out and whether you even can
> do as many so I'm only reporting from my experience, in case you were
> wondering what you could improve:
> 
> People push branches to their trees and wait for the robot to test them.
> And they wait and wait. But instead, such silly warnings come.
> 
> So it would be a lot better if you could expedite such pushed branches'
> build tests first and then the rest.

Got it. Internally, we use the merge strategy to combine as many branches
as we can to run build testing, and bisect the issues if found. We need
further think of how to let high priority issues to be reported out earlier.

> 
> And then if there are no branches, submitted patchsets on the ML.
> 
> If you're trying to figure out what base to use, you can put a doc
> somewhere telling people how to specify the base for you and they will
> start doing it, you will parse the 0th message for that info and use the
> base.

Thanks, so far, we recommend to use --base option in our report mail, like

	[If your patch is applied to the wrong git tree, kindly drop us a note.
	And when submitting patch, we suggest to use '--base' as documented in
	https://git-scm.com/docs/git-format-patch#_base_tree_information]

And we do need a place to put such information, so people can refer to. Without
a public available site for us, we will update https://github.com/intel/lkp-tests/wiki
firstly to host enough information.

> 
> And the long-standing feature request we have: a simple web page
> somewhere which says how far is it with testing. So that people can go
> and look at it and know whether to wait for test results before sending.

Really apologize for this. Yes, we got the request long before, we did some
attempts to resolve this with a web site to show the progress, but it wasn't
able to be public yet.

> 
> The web page doesn't have to be anything special - just a table of
> branches being tested at the moment.

Thanks for the hint, this is doable, and we definitely need do this. I will
plan it to have initial version ready by Q1.

> 
> Anyway, I thought I should give you some suggestions if you were looking
> for some. :-)

Thanks a lot Boris, these suggestions are very helpful to further improve the
0-day ci service.

> 
> Thanks for the testing work - it is appreciated!
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette