lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAErSpo4qEPQq==rmzy+8a2FHgaKmWbG7BvopKqbBZC551kgdcg@mail.gmail.com>
Date:	Thu, 29 Aug 2013 16:22:22 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Yijing Wang <wangyijing@...wei.com>, Jon Mason <jdmason@...zu.us>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Hanjun Guo <guohanjun@...wei.com>,
	Jiang Liu <jiang.liu@...wei.com>,
	Jin Feng <joe.jin@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v8 6/6] PCI: update device mps when doing pci hotplug

On Thu, Aug 29, 2013 at 3:47 PM, Yinghai Lu <yinghai@...nel.org> wrote:
> On Thu, Aug 29, 2013 at 2:09 PM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
>> [+cc linux-kernel, since more folks might be interested]
>
>> I don't know what the BIOS "auto" setting means, but it must mean
>> something in case 3, because that's the only case where OS support is
>> required.  But if the OS is smart enough to manage MPS for hot-added
>> devices, why can't the OS also program MPS for the whole system at
>> boot-time?
>>
>> That's why I don't understand what BIOS wants to do.  It sounds like
>> they want the performance benefit of larger MPS for devices present in
>> hot-plug slots at boot-time, even if the OS doesn't actively manage
>> MPS and things blow up if that device is replaced with one that
>> supports a smaller MPS.  That choice doesn't make sense.
>>
>> In case 3, with a non-MPS-aware OS, you get better performance for a
>> while, but blow up if a card is replaced.  And with an MPS-aware OS,
>> there should be no advantage to case 3: the OS should be able to get
>> good performance by programming MPS itself, even without help from the
>> BIOS.
>
> With OS default setting on case 3, other two OS are ok with hotplug,
> but Linux does not.

I'm not disputing that.  I said plainly that in case 3, things blow up
if the OS doesn't actively manage MPS.  By default Linux doesn't touch
MPS, so it blows up if a card is replaced.

I am suggesting that it doesn't make any sense for a BIOS to use case
3.  Please make an argument for why it *does* make sense to use case
3.

Note that I think Linux *should* eventually actively manage MPS, and
when it does, case 3 should "just work".  I just don't understand what
the point of the BIOS using case 3 is.

I suppose other OSes must get better performance in this "auto" mode?
(What exactly is that mode, anyway?)  That means the other OS must be
smart enough to deal with hotplug device replacement, but not smart
enough to configure MPS all by itself starting from scratch.  I don't
know what rules would tell us "this MPS must be configured by the BIOS
and the OS should leave it alone" and "the OS must configure MPS on
this device for hotplug."  How can we make sense out of that?

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ