lkml.org 
[lkml]   [2010]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 05/11] pci: update bridge res to get more big range in pci assign unssign
* Yinghai Lu <yinghai@kernel.org>:
> BIOS separate IO range between several IOHs, and on some slots,
> BIOS assign the resource to the bridge, but stop assigning
> resource to the device under that bridge, because the device
> need big resource.
>
> 1. pci assign unassign and record the failed device resource.
> 2. clear the BIOS assigned resource of the parent bridge of fail device
> 3. go back and call pci assign unsigned
> 4. if it still fail, will go up more bridges. and clear and try again.

I agree with Jesse and Bjorn. I really hate introducing a new
command line param.

The goal here should be to do the right thing, all the time,
without requiring command line parameters.

I understand that you are avoiding a change to existing behavior
by defaulting to try=1.

What I don't understand is how you expect your change to benefit
any actual users. The usage model you propose is:

- user encounters failure

- user emails lkml/linux-pci and says "why doesn't my
device get resources?"

- we tell user, "please reboot with try=N for increasing
values of N until it works"

Why shouldn't we be aggressive all the time?

If this patch series is going to be accepted, we should turn it
on all the time. Everyone will get the benefits.

If it breaks machines, depending on the bug reports, it will end
up either:

a) we missed an implementation detail (easily fixed)

or

b) the design/strategy is wrong, in which case we need to
take a step back and think about a different approach to
solve the problem you're trying to solve

For this patch, I don't mind the changes to
pci_assign_unassigned_resources(), but I really do not agree with
the configurability introduced in pci_setup().

thanks,
/ac


\
 
 \ /
  Last update: 2010-01-16 05:41    [W:0.190 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site