2013/10/23 Michael Chang :
> 2013/10/23 Konrad Rzeszutek Wilk :
>> On Tue, Oct 22, 2013 at 03:25:39PM +, Woodhouse, David wrote:
>>> On Tue, 2013-10-22 at 10:43 -0400, Konrad Rzeszutek Wilk wrote:
>>> >
>>> > And looking at bit deeper in the x86/linu
2013/10/23 Konrad Rzeszutek Wilk :
> On Tue, Oct 22, 2013 at 03:25:39PM +, Woodhouse, David wrote:
>> On Tue, 2013-10-22 at 10:43 -0400, Konrad Rzeszutek Wilk wrote:
>> >
>> > And looking at bit deeper in the x86/linux boot spec:
>> >
>> > EFI HANDOVER PROTOCOL
>> >
>> > This protocol
2013/10/23 Konrad Rzeszutek Wilk konrad.w...@oracle.com:
On Tue, Oct 22, 2013 at 03:25:39PM +, Woodhouse, David wrote:
On Tue, 2013-10-22 at 10:43 -0400, Konrad Rzeszutek Wilk wrote:
And looking at bit deeper in the x86/linux boot spec:
EFI HANDOVER PROTOCOL
This protocol
2013/10/23 Michael Chang mch...@suse.com:
2013/10/23 Konrad Rzeszutek Wilk konrad.w...@oracle.com:
On Tue, Oct 22, 2013 at 03:25:39PM +, Woodhouse, David wrote:
On Tue, 2013-10-22 at 10:43 -0400, Konrad Rzeszutek Wilk wrote:
And looking at bit deeper in the x86/linux boot spec
and cleanly unmount the filesystem that was
> using it? (and preferably put it all back together after resume).
>
If you lose the device key, how are you going to get luks to find it
again when resuming? Wouldn't it make more sense to have it remember
the key? I can't see it being advisabl
...
--
Michael Chang
Please avoid sending me Word or PowerPoint attachments. Send me ODT,
RTF, or HTML instead.
See http://www.gnu.org/philosophy/no-word-attachments.html
Thank you.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
boot.
(The scripts gives info about CPU characteristics, interrupts,
modules, etc. -- you know, all those "unknown" variables.)
And perhaps a patch to show what parts you commented out, too, so one
can tell if anything got broken (unintentionally).
--
Michael Chang
Please avoid
info about CPU characteristics, interrupts,
modules, etc. -- you know, all those unknown variables.)
And perhaps a patch to show what parts you commented out, too, so one
can tell if anything got broken (unintentionally).
--
Michael Chang
Please avoid sending me Word or PowerPoint attachments
f the Linux RTC (realtime clock - /dev/rtc) as
timing mechanism. This wakes up the process every 1/1024 seconds to
check the current time. Useless with modern Linux kernels configured
for desktop use as they already wake up the process with similar
accuracy when using normal timed sleep.
[1] MPlayer de
every 1/1024 seconds to
check the current time. Useless with modern Linux kernels configured
for desktop use as they already wake up the process with similar
accuracy when using normal timed sleep.
[1] MPlayer dev-SVN-r23777-4.1.2 (C) 2000-2007 MPlayer Team
--
Michael Chang
Please avoid sending
saying?
> I'm happy that SD was perfect for you. It wasn't for others, and it had
> nobody who was even interested in trying to solve those issues.
--
Michael Chang
Please avoid sending me Word or PowerPoint attachments. Send me ODT,
RTF, or HTML instead.
See http://www.gnu.org/philo
, and it had
nobody who was even interested in trying to solve those issues.
--
Michael Chang
Please avoid sending me Word or PowerPoint attachments. Send me ODT,
RTF, or HTML instead.
See http://www.gnu.org/philosophy/no-word-attachments.html
Thank you.
-
To unsubscribe from this list: send the line
lso appears a bit dated on sourceforge... release
0.4.0 on 2006-01-15.
Just thought I'd mention it.
--
Michael Chang
Please avoid sending me Word or PowerPoint attachments. Send me ODT,
RTF, or HTML instead.
See http://www.gnu.org/philosophy/no-word-attachments.html
Thank you.
-
To unsu
nlikely for some other reason which
alludes me at the moment?)
--
Michael Chang
Please avoid sending me Word or PowerPoint attachments. Send me ODT,
RTF, or HTML instead.
See http://www.gnu.org/philosophy/no-word-attachments.html
Thank you.
-
To unsubscribe from this list: send the line "unsub
switching from state A to state B, and from B to C,
etc.; wouldn't it be a bad thing if state B happened to be (in the
future) this state-shifting userspace daemon of which you speak? (Or
is that likely to be impossible/unlikely for some other reason which
alludes me at the moment?)
--
Michael Chang
thought I'd mention it.
--
Michael Chang
Please avoid sending me Word or PowerPoint attachments. Send me ODT,
RTF, or HTML instead.
See http://www.gnu.org/philosophy/no-word-attachments.html
Thank you.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
models sold with low-end sub $500 PCs...
--
Michael Chang
Please avoid sending me Word or PowerPoint attachments. Send me ODT,
RTF, or HTML instead.
See http://www.gnu.org/philosophy/no-word-attachments.html
Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
e that appear to be
supporting this patch. I can only wonder whether it's possible this
request never got to any of them.
--
Michael Chang
Please avoid sending me Word or PowerPoint attachments. Send me ODT,
RTF, or HTML instead.
See http://www.gnu.org/philosophy/no-word-attachments.html
Thank you.
-
T
of them.
--
Michael Chang
Please avoid sending me Word or PowerPoint attachments. Send me ODT,
RTF, or HTML instead.
See http://www.gnu.org/philosophy/no-word-attachments.html
Thank you.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
with low-end sub $500 PCs...
--
Michael Chang
Please avoid sending me Word or PowerPoint attachments. Send me ODT,
RTF, or HTML instead.
See http://www.gnu.org/philosophy/no-word-attachments.html
Thank you.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
th the code
compensating for its own activity in the "detect activity" mechanism
-- assuming there wasn't a major impact in e.g. maintainability or
something.
As for the burstyness... considering the "no negative impact" stance,
I can understand that. But it seems inefficient, a
...
--
Michael Chang
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
Thank you.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
w,
anyways, is that swap prefetch should provide... "something for
(almost) nothing", if I'm interpreting this right.)
That said, there are probably some cases (seti) where swap prefetch
during the run of that batch program would help. On the flip side,
there are also some cases where ba
of memory, meaning that
performing the prefetch at that time is futile, unhelpful, or
otherwise unwanted.
Would it be better to be less yield-y in this circumstance?
--
Michael Chang
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
ven lower, maybe <0.75 or <2?) and that is not a "niced"
load.
--
-- Michael Chang
~Just the crazy copy cat~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
load.
--
-- Michael Chang
~Just the crazy copy cat~
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
e of
a nice 0, but I'm not sure how that would scale to nice 19 or nice
-19.
--
-- Michael Chang
~Just the crazy copy cat~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
attempted to
answer Con's question of how much CPU a nice 5 process should get
relative to nice 0, etc., apart from maybe Con himself.
Personally, I think a nice 5 process should get 50% of the CPU time of
a nice 0, but I'm not sure how that would scale to nice 19 or nice
-19.
--
-- Michael Chang
On 3/13/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
On Tue, Mar 13, 2007 at 02:05:23PM +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 10:46, David Miller wrote:
> > From: Con Kolivas <[EMAIL PROTECTED]>
> > Date: Mon, 12 Mar 2007 10:58:11 +1100
> >
> > >
On 3/13/07, Willy Tarreau [EMAIL PROTECTED] wrote:
On Tue, Mar 13, 2007 at 02:05:23PM +1100, Con Kolivas wrote:
On Tuesday 13 March 2007 10:46, David Miller wrote:
From: Con Kolivas [EMAIL PROTECTED]
Date: Mon, 12 Mar 2007 10:58:11 +1100
and is
currently in vanilla.
To me, that fundamentally clashes with the design behind RSDL. That
said, I could be wrong -- Con appears to have something that could be
very promising up his sleeve that could come out sooner or later. Once
he's written it, of course. In any case, RSDL seems very promising,
for the most part.
--
Michael Chang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 3/12/07, jos poortvliet <[EMAIL PROTECTED]> wrote:
Op Monday 12 March 2007, schreef Al Boldi:
>
> It only takes one negatively nice'd proc to affect X adversely.
goes faster than ever)? Or is this really the scheduler's fault?
Take this with a grain of salt, but, I don't think this is the
On 3/12/07, jos poortvliet [EMAIL PROTECTED] wrote:
Op Monday 12 March 2007, schreef Al Boldi:
It only takes one negatively nice'd proc to affect X adversely.
goes faster than ever)? Or is this really the scheduler's fault?
Take this with a grain of salt, but, I don't think this is the
behind RSDL. That
said, I could be wrong -- Con appears to have something that could be
very promising up his sleeve that could come out sooner or later. Once
he's written it, of course. In any case, RSDL seems very promising,
for the most part.
--
Michael Chang
-
To unsubscribe from this list: send
On 3/10/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
On Sat, Mar 10, 2007 at 04:56:57PM -0500, michael chang wrote:
> On 3/10/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> >BTW, Con, I think that you should base your work on 2.6.20.[23] and not
> >2.6.20 next
On 3/10/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
BTW, Con, I think that you should base your work on 2.6.20.[23] and not
2.6.20 next time, due to this conflict. It will get wider adoption.
Maybe I'm naive, but I find this hard to understand -- 2.6.20.2 didn't
exist when Con published his
On 3/10/07, Willy Tarreau [EMAIL PROTECTED] wrote:
BTW, Con, I think that you should base your work on 2.6.20.[23] and not
2.6.20 next time, due to this conflict. It will get wider adoption.
Maybe I'm naive, but I find this hard to understand -- 2.6.20.2 didn't
exist when Con published his
On 3/10/07, Willy Tarreau [EMAIL PROTECTED] wrote:
On Sat, Mar 10, 2007 at 04:56:57PM -0500, michael chang wrote:
On 3/10/07, Willy Tarreau [EMAIL PROTECTED] wrote:
BTW, Con, I think that you should base your work on 2.6.20.[23] and not
2.6.20 next time, due to this conflict. It will get
On 2/17/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
On Sunday 18 February 2007 05:45, Chuck Ebbert wrote:
> Con Kolivas wrote:
> > Maintainers are far too busy off testing code for
> > 16+ cpus, petabytes of disk storage and so on to try it for themselves.
> > Plus they worry incessantly that my
On 2/16/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
On Saturday 17 February 2007 13:15, michael chang wrote:
> On 2/16/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
> > I'm thru with bashing my head against the wall.
>
> I do hope this post isn't in any way redundant
On 2/16/07, Con Kolivas [EMAIL PROTECTED] wrote:
On Saturday 17 February 2007 13:15, michael chang wrote:
On 2/16/07, Con Kolivas [EMAIL PROTECTED] wrote:
I'm thru with bashing my head against the wall.
I do hope this post isn't in any way redundant, but from what I can
see, this has never
On 2/17/07, Con Kolivas [EMAIL PROTECTED] wrote:
On Sunday 18 February 2007 05:45, Chuck Ebbert wrote:
Con Kolivas wrote:
Maintainers are far too busy off testing code for
16+ cpus, petabytes of disk storage and so on to try it for themselves.
Plus they worry incessantly that my patches
On 2/16/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
I'm thru with bashing my head against the wall.
I do hope this post isn't in any way redundant, but from what I can
see, this has never been suggested... (someone please do enlighten me
if I'm wrong.)
Has anyone tried booting a kernel with
On 2/16/07, Con Kolivas [EMAIL PROTECTED] wrote:
I'm thru with bashing my head against the wall.
I do hope this post isn't in any way redundant, but from what I can
see, this has never been suggested... (someone please do enlighten me
if I'm wrong.)
Has anyone tried booting a kernel with the
44 matches
Mail list logo
