On 04/29/2016 11:37 AM, Richard W.M. Jones wrote:
On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote:
On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote:
On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote:
On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones
On 04/29/2016 11:37 AM, Richard W.M. Jones wrote:
On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote:
On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote:
On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote:
On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones
On Fri, Apr 29, 2016 at 05:02:57PM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 29, 2016 at 08:54:13AM -0700, Greg KH wrote:
> > You are trying to take a generalized kernel and somehow "know" about the
> > hardware ahead of time it is going to run on. That seems like two
> > conflicting
On Fri, Apr 29, 2016 at 05:02:57PM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 29, 2016 at 08:54:13AM -0700, Greg KH wrote:
> > You are trying to take a generalized kernel and somehow "know" about the
> > hardware ahead of time it is going to run on. That seems like two
> > conflicting
On Fri, Apr 29, 2016 at 08:54:13AM -0700, Greg KH wrote:
> You are trying to take a generalized kernel and somehow "know" about the
> hardware ahead of time it is going to run on. That seems like two
> conflicting requirements, don't you agree?
We would have the 8250 serial port in any kernel.
On Fri, Apr 29, 2016 at 08:54:13AM -0700, Greg KH wrote:
> You are trying to take a generalized kernel and somehow "know" about the
> hardware ahead of time it is going to run on. That seems like two
> conflicting requirements, don't you agree?
We would have the 8250 serial port in any kernel.
On Fri, Apr 29, 2016 at 04:37:57PM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote:
> > On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote:
> > > On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote:
> > > > On Thu, Apr 28, 2016 at
On Fri, Apr 29, 2016 at 04:37:57PM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote:
> > On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote:
> > > On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote:
> > > > On Thu, Apr 28, 2016 at
On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote:
> On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote:
> > On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote:
> > > On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote:
> > > > Currently autoconf spends
On Fri, Apr 29, 2016 at 08:16:35AM -0700, Greg KH wrote:
> On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote:
> > On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote:
> > > On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote:
> > > > Currently autoconf spends
On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote:
> On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote:
> > On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote:
> > > Currently autoconf spends 25ms (on my laptop) testing if the UART
> > > exported to it by KVM
On Fri, Apr 29, 2016 at 09:10:06AM +0100, Richard W.M. Jones wrote:
> On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote:
> > On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote:
> > > Currently autoconf spends 25ms (on my laptop) testing if the UART
> > > exported to it by KVM
On Fri, Apr 29, 2016 at 08:41:14AM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 29, 2016 at 10:01:08AM +0300, Matwey V. Kornilov wrote:
> > 2016-04-29 1:18 GMT+03:00 Richard W.M. Jones :
> > > [This is an opinionated patch, mainly for discussion.]
> > >
> > > I'm trying to
On Fri, Apr 29, 2016 at 08:41:14AM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 29, 2016 at 10:01:08AM +0300, Matwey V. Kornilov wrote:
> > 2016-04-29 1:18 GMT+03:00 Richard W.M. Jones :
> > > [This is an opinionated patch, mainly for discussion.]
> > >
> > > I'm trying to reduce the time taken
On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote:
> On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote:
> > Currently autoconf spends 25ms (on my laptop) testing if the UART
> > exported to it by KVM is an 8250 without FIFO and/or with strange
> > quirks, which it obviously
On Thu, Apr 28, 2016 at 03:56:33PM -0700, Greg KH wrote:
> On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote:
> > Currently autoconf spends 25ms (on my laptop) testing if the UART
> > exported to it by KVM is an 8250 without FIFO and/or with strange
> > quirks, which it obviously
On Fri, Apr 29, 2016 at 10:01:08AM +0300, Matwey V. Kornilov wrote:
> 2016-04-29 1:18 GMT+03:00 Richard W.M. Jones :
> > [This is an opinionated patch, mainly for discussion.]
> >
> > I'm trying to reduce the time taken in the kernel in initcalls, with
> > my aim being to reduce
On Fri, Apr 29, 2016 at 10:01:08AM +0300, Matwey V. Kornilov wrote:
> 2016-04-29 1:18 GMT+03:00 Richard W.M. Jones :
> > [This is an opinionated patch, mainly for discussion.]
> >
> > I'm trying to reduce the time taken in the kernel in initcalls, with
> > my aim being to reduce the current ~700ms
2016-04-29 1:18 GMT+03:00 Richard W.M. Jones :
> [This is an opinionated patch, mainly for discussion.]
>
> I'm trying to reduce the time taken in the kernel in initcalls, with
> my aim being to reduce the current ~700ms spent in initcalls before
> userspace, down to something
2016-04-29 1:18 GMT+03:00 Richard W.M. Jones :
> [This is an opinionated patch, mainly for discussion.]
>
> I'm trying to reduce the time taken in the kernel in initcalls, with
> my aim being to reduce the current ~700ms spent in initcalls before
> userspace, down to something like 100ms. All
On 04/28/2016 03:18 PM, Richard W.M. Jones wrote:
> [This is an opinionated patch, mainly for discussion.]
>
> I'm trying to reduce the time taken in the kernel in initcalls, with
> my aim being to reduce the current ~700ms spent in initcalls before
> userspace, down to something like 100ms. All
On 04/28/2016 03:18 PM, Richard W.M. Jones wrote:
> [This is an opinionated patch, mainly for discussion.]
>
> I'm trying to reduce the time taken in the kernel in initcalls, with
> my aim being to reduce the current ~700ms spent in initcalls before
> userspace, down to something like 100ms. All
On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote:
> Currently autoconf spends 25ms (on my laptop) testing if the UART
> exported to it by KVM is an 8250 without FIFO and/or with strange
> quirks, which it obviously isn't. Assume it is exported to us by a
> hypervisor, it's a
On Thu, Apr 28, 2016 at 11:18:33PM +0100, Richard W.M. Jones wrote:
> Currently autoconf spends 25ms (on my laptop) testing if the UART
> exported to it by KVM is an 8250 without FIFO and/or with strange
> quirks, which it obviously isn't. Assume it is exported to us by a
> hypervisor, it's a
[This is an opinionated patch, mainly for discussion.]
I'm trying to reduce the time taken in the kernel in initcalls, with
my aim being to reduce the current ~700ms spent in initcalls before
userspace, down to something like 100ms. All times on my Broadwell-U
laptop, under virtualization. The
[This is an opinionated patch, mainly for discussion.]
I'm trying to reduce the time taken in the kernel in initcalls, with
my aim being to reduce the current ~700ms spent in initcalls before
userspace, down to something like 100ms. All times on my Broadwell-U
laptop, under virtualization. The
Currently autoconf spends 25ms (on my laptop) testing if the UART
exported to it by KVM is an 8250 without FIFO and/or with strange
quirks, which it obviously isn't. Assume it is exported to us by a
hypervisor, it's a normal, working 16550A.
Signed-off-by: Richard W.M. Jones
Currently autoconf spends 25ms (on my laptop) testing if the UART
exported to it by KVM is an 8250 without FIFO and/or with strange
quirks, which it obviously isn't. Assume it is exported to us by a
hypervisor, it's a normal, working 16550A.
Signed-off-by: Richard W.M. Jones
---
28 matches
Mail list logo