There are many places in the kernel where the construction like
foo = list_entry(head->next, struct foo_struct, list);
are used.
The code might look more descriptive and neat if using the macro
list_first_entry(head, type, member) \
list_entry((head)->next, type, member)
Her
On Wed, Apr 18, 2007 at 12:55:25AM -0500, Matt Mackall wrote:
> On Wed, Apr 18, 2007 at 07:00:24AM +0200, Nick Piggin wrote:
> > > It's also not yet clear that a scheduler can't be taught to do the
> > > right thing with X without fiddling with nice levels.
> >
> > Being fair doesn't prevent that.
Dave Hansen wrote:
> On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
>> +#define SHOW_TOP_SLABS 10
>
> Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. "Should
> I show the top slabs?"
>
> This might be a bit more clear:
>
> #define TOP_NR_SLABS_TO_SHOW 10
>
> or
>
>
Max Kellermann wrote:
Yet another hard drive which doesn't seem to get NCQ right.
ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl
0x1501000 status 0x400 next cpb count 0xB next cpb idx 0x0
[...]
ata1: timeout waiting for ADMA IDLE, stat=0x400
ata1: timeout waiting for ADMA LE
On 4/17/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
I am still somewhat unhappy about the spinlock, but I don't really
have a better suggestion either. Other than that, looks good to me.
On Tue, 17 Apr 2007, Eric Dumazet wrote:
> This nr_pages should be in struct kmem_list3, not in struct kmem_cache,
> or else you defeat NUMA optimizations if touching a field in kmem_cache
> at kmem_getpages()/kmem_freepages() time.
We already touch ->flags, ->gfpflags, and ->gfporder in kmem_ge
Yet another hard drive which doesn't seem to get NCQ right.
ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl
0x1501000 status 0x400 next cpb count 0xB next cpb idx 0x0
[...]
ata1: timeout waiting for ADMA IDLE, stat=0x400
ata1: timeout waiting for ADMA LEGACY, stat=0x400
ata1.0
* Michael Ellerman <[EMAIL PROTECTED]> wrote:
> Apparently it's not cool anymore to use SPIN/RW_LOCK_UNLOCKED. There's
> some mention of this in Documentation/spinlocks.txt, but that only
> talks about dynamic initialisation.
>
> A comment in the code mentioning the preferred usage would be go
On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
> > +#define SHOW_TOP_SLABS 10
On Tue, 17 Apr 2007, Dave Hansen wrote:
> Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. "Should
> I show the top slabs?"
>
> This might be a bit more clear:
>
> #define TOP_NR_SLABS_TO_SHO
On Wed, Apr 18, 2007 at 07:00:24AM +0200, Nick Piggin wrote:
> > It's also not yet clear that a scheduler can't be taught to do the
> > right thing with X without fiddling with nice levels.
>
> Being fair doesn't prevent that. Implicit unfairness is wrong though,
> because it will bite people.
>
Peter Williams wrote:
Chris Friesen wrote:
Suppose I have a really high priority task running. Another very high
priority task wakes up and would normally preempt the first one.
However, there happens to be another cpu available. It seems like it
would be a win if we moved one of those tas
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linux-kernel-
> [EMAIL PROTECTED] On Behalf Of Bill Davidsen
> Sent: dinsdag 17 april 2007 21:38
> To: linux-kernel@vger.kernel.org
> Cc: Buytaert, Steven; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
> Subject: Re: sched_yield pro
On Tue, 17 Apr 2007 22:14:02 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]>
wrote:
>
>
> On Tue, 17 Apr 2007, Florin Iucha wrote:
> >
> > Already did. Traces from vanilla kernel at
> >http://iucha.net/nfs/21-rc7/big-copy
>
> Well, there's a pdflush in io_schedule_timeout/congestion_wait,
Mark Lord wrote:
> Chuck Ebbert wrote:
>> Mark Lord wrote:
>>> I'll patch it locally on my own machines, but what about the tens
>>> of thousands of other Seagate notebook drive owners out there?
>>>
>>
>> This is a problem with Seagate specifically, spinning back up
>> on receipt of some command a
On Tue, Apr 17, 2007 at 10:14:02PM -0700, Linus Torvalds wrote:
> On Tue, 17 Apr 2007, Florin Iucha wrote:
> >
> > Already did. Traces from vanilla kernel at
> >http://iucha.net/nfs/21-rc7/big-copy
>
> Well, there's a pdflush in io_schedule_timeout/congestion_wait, and
> there's a nfsv4-scv
On Tue, 17 Apr 2007, Florin Iucha wrote:
>
> Already did. Traces from vanilla kernel at
>http://iucha.net/nfs/21-rc7/big-copy
Well, there's a pdflush in io_schedule_timeout/congestion_wait, and
there's a nfsv4-scv in svc_recv/nfs_callback_sv, and a lot of processes
either just in schedul
On Tue, Apr 17, 2007 at 11:38:31PM -0500, Matt Mackall wrote:
> On Wed, Apr 18, 2007 at 05:15:11AM +0200, Nick Piggin wrote:
> >
> > I don't know why this would be a useful feature (of course I'm talking
> > about processes at the same nice level). One of the big problems with
> > the current sche
I'm back working on the serial driver to try to get the necessary
changes so the IPMI driver can use it. This patch is sort of asking
if this is the right direction to go for now. I have all the drivers
that use serial_core.h converted over, and if this is accepted I can
send the whole set.
Subj
On Wed, 18 Apr 2007, Yasunori Goto wrote:
> If panic_on_oom is 1, only panic if mempolicy/cpuset is not used.
> And if panic_on_oom is 2, panic on all case.
> This might be desirable.
Sounds good. Add some documentation mentioned that this may panic your
system if there is still plenty of memory
On Tuesday 17 April 2007 13:19, John Anthony Kazos Jr. wrote:
> /*
> - * Samma på svenska..
> + * Samma på svenska..
> */
Translating this comment into english so more people could understand it
would be better option.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe lin
On Wednesday 18 April 2007, H. Peter Anvin wrote:
>Gene Heskett wrote:
>> On Tuesday 17 April 2007, H. Peter Anvin wrote:
>>> Gene Heskett wrote:
I have the usual fd0, a 3.5" 1.44 drive, and fd1, a 5.25" 720k drive in
this machine, both are enabled in the bios with the correct types being
On Wed, Apr 18, 2007 at 05:15:11AM +0200, Nick Piggin wrote:
> On Tue, Apr 17, 2007 at 04:39:54PM -0500, Matt Mackall wrote:
> > On Tue, Apr 17, 2007 at 09:01:55AM +0200, Nick Piggin wrote:
> > > On Mon, Apr 16, 2007 at 11:26:21PM -0700, William Lee Irwin III wrote:
> > > > On Mon, Apr 16, 2007 at
On Tue, 17 Apr 2007, Larry Woodman wrote:
> On Tue, 2007-04-17 at 14:39 -0700, Christoph Lameter wrote:
>
> >
> > It recreates the old problem that we OOM while we still have memory
> > in other parts of the system.
>
> How, by the time we get here we have already decided we are going to
> OOM
On Wednesday 18 April 2007, H. Peter Anvin wrote:
>Gene Heskett wrote:
>> On Tuesday 17 April 2007, H. Peter Anvin wrote:
>>> Gene Heskett wrote:
I have the usual fd0, a 3.5" 1.44 drive, and fd1, a 5.25" 720k drive in
this machine, both are enabled in the bios with the correct types being
William Lee Irwin III wrote:
> Ingo Molnar wrote:
> >> Anyone who thinks that there exists only two kinds of code: 100%
> >> correct and 100% incorrect with no shades of grey inbetween is in
> >> reality a sort of an extremist: whom, depending on mood and affection,
> >> we could call either a 'cod
> My test machine is a Dell Precision 490 with dual 5140 processors and
> 3GB of RAM. If I reduced kMaxSize to (2048 * 2048 * 236) is works.
> However, I need to allocate an array of char that is (2048 * 2048 * 256)
> and maybe even as large at (2048 * 2048 * 512).
>
> Obviously I have enough phy
On Tue, Apr 17, 2007 at 11:16:54PM +1000, Peter Williams wrote:
> Nick Piggin wrote:
> >I don't like the timeslice based nice in mainline. It's too nasty
> >with latencies. nicksched is far better in that regard IMO.
> >
> >But I don't know how you can assert a particular way is the best way
> >to
On Tuesday 17 April 2007 8:10 pm, Len Brown wrote:
> On Thursday 12 April 2007 17:14, David Brownell wrote:
> > --- g26.orig/drivers/acpi/glue.c2007-04-12 10:56:35.0 -0700
> > +++ g26/drivers/acpi/glue.c 2007-04-12 10:56:35.0 -0700
> > @@ -316,13 +316,19 @@ static int __init ac
On Tue, 17 Apr 2007, William Lee Irwin III wrote:
> 100**(1/39.0) ~= 1.12534 may do if so, but it seems a little weak, and
> even 1000**(1/39.0) ~= 1.19378 still seems weak.
>
> I suspect that in order to get low nice numbers strong enough without
> making high nice numbers too strong something s
Gene Heskett wrote:
On Tuesday 17 April 2007, H. Peter Anvin wrote:
Gene Heskett wrote:
I have the usual fd0, a 3.5" 1.44 drive, and fd1, a 5.25" 720k drive in
this machine, both are enabled in the bios with the correct types being
set there.
A 5.25" 720k drive?! That's not a PC standard driv
Siddha, Suresh B a écrit :
Christoph,
While going through the slab code, I observed that alien caches are
not getting resized, when user changes the slab tunables. Appended patch
tries to fix this. Please review and let me know if I missed anything.
thanks,
suresh
---
Resize the alien caches t
On Tue, Apr 17, 2007 at 09:13:50PM -0700, Andrew Morton wrote:
> On Tue, 17 Apr 2007 23:07:30 -0500 [EMAIL PROTECTED] (Florin Iucha) wrote:
> > > > The process traces are at:
> > > >
> > > >http://iucha.net/nfs/21-rc7-nfs1/gnome-session
> > > >http://iucha.net/nfs/21-rc7-nfs1/big-copy
>
>
On Mon, 16 Apr 2007 20:25:15 -0700
Mike Mattie <[EMAIL PROTECTED]> wrote:
I have added Sergei Shtylyov to the address list after seeing his recent posts
on hpt366 issues, and the
git changelog for the hpt366.c driver. I am very confident that I have
pinpointed the defect in the driver.
> On Mon
On Wed, 2007-04-18 at 05:56 +0200, Nick Piggin wrote:
> On Wed, Apr 18, 2007 at 05:45:20AM +0200, Mike Galbraith wrote:
> > On Wed, 2007-04-18 at 05:15 +0200, Nick Piggin wrote:
> > >
> > >
> > > So on what basis would you allow unfairness? On the basis that it doesn't
> > > seem to harm anyone? I
On Tue, Apr 17, 2007 at 09:07:49AM -0400, James Bruce wrote:
>>> Nonlinear is a must IMO. I would suggest X = exp(ln(10)/10) ~= 1.2589
>>> That value has the property that a nice=10 task gets 1/10th the cpu of a
>>> nice=0 task, and a nice=20 task gets 1/100 of nice=0. I think that
>>> would be f
On Saturday 14 April 2007 12:09, Éric Piel wrote:
> This patch adds support for mail and wifi leds. It modifies the Kconfig
> file to automatically pull led_class with wistron_btns, hopefully
> everyone is fine with this.
>
Was there 1/2 file?
--
Dmitry
-
To unsubscribe from this list: send t
On Tue, 17 Apr 2007 23:07:30 -0500 [EMAIL PROTECTED] (Florin Iucha) wrote:
> On Tue, Apr 17, 2007 at 11:54:45PM -0400, Trond Myklebust wrote:
> > > The good news is that the Gnome session log-in progresses to the point
> > > where both top and bottom bars are painted (gray) and the bottom bar
> >
On Tue, Apr 17, 2007 at 11:54:45PM -0400, Trond Myklebust wrote:
> > The good news is that the Gnome session log-in progresses to the point
> > where both top and bottom bars are painted (gray) and the bottom bar
> > is populated with icons (2.6.21-rc7 vanilla stops after displaying the
> > splash)
On Wed, Apr 18, 2007 at 05:45:20AM +0200, Mike Galbraith wrote:
> On Wed, 2007-04-18 at 05:15 +0200, Nick Piggin wrote:
> > On Tue, Apr 17, 2007 at 04:39:54PM -0500, Matt Mackall wrote:
> > >
> > > I'm a big fan of fairness, but I think it's a bit early to declare it
> > > a mandatory feature. Bou
On Tue, 2007-04-17 at 22:30 -0500, Florin Iucha wrote:
> On Tue, Apr 17, 2007 at 11:06:05PM -0400, Trond Myklebust wrote:
> > > > I've split the issues introduced by the 2.6.21-rcX write code up into 4
> > > > subproblems.
> > > >
> > > > The first patch is just a cleanup in order to ease review.
On Tue, Apr 17, 2007 at 11:06:05PM -0400, Trond Myklebust wrote:
> > > I've split the issues introduced by the 2.6.21-rcX write code up into 4
> > > subproblems.
> > >
> > > The first patch is just a cleanup in order to ease review.
> > >
> > > Patch number 2 ensures that we never release the PG_
On Wed, 2007-04-18 at 05:15 +0200, Nick Piggin wrote:
> On Tue, Apr 17, 2007 at 04:39:54PM -0500, Matt Mackall wrote:
> >
> > I'm a big fan of fairness, but I think it's a bit early to declare it
> > a mandatory feature. Bounded unfairness is probably something we can
> > agree on, ie "if we decid
>Asides from git-bisect failing me again[1], what gives with this file?
it supports output switching, which didn't make it into 2.6.21 --
probably will be 2.6.22.
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
On Tuesday 17 April 2007 8:03 pm, Greg KH wrote:
> On Tue, Apr 17, 2007 at 02:57:49PM -0700, David Brownell wrote:
> > Looks like the i8042 serial nodes will be bizarre too:
> >
> > /sys/devices/pnp0/00:09
> > ... touchpad's PNP node
> > /sys/devices/acpi_system:00/device:00/P
On Tue, Apr 17, 2007 at 05:08:48PM -0500, Serge E. Hallyn wrote:
> Quoting Bharata B Rao ([EMAIL PROTECTED]):
> > From: Jan Blunck <[EMAIL PROTECTED]>
> > Subject: Introduce union stack.
> >
> > Adds union stack infrastructure to the dentry structure and provides
> > locking routines to walk the u
On Tue, Apr 17, 2007 at 04:39:54PM -0500, Matt Mackall wrote:
> On Tue, Apr 17, 2007 at 09:01:55AM +0200, Nick Piggin wrote:
> > On Mon, Apr 16, 2007 at 11:26:21PM -0700, William Lee Irwin III wrote:
> > > On Mon, Apr 16, 2007 at 11:09:55PM -0700, William Lee Irwin III wrote:
> > > >> All things ar
On Thursday 12 April 2007 17:14, David Brownell wrote:
> This works around a bug seen in some RTC-related ACPI table entries, and
> tweaks related diagnostics to follow the ACPI convention.
>
> The bug prevents misleading boot-time messages: platforms affected by this
> bug wrongly report they ca
On Tuesday 17 April 2007, H. Peter Anvin wrote:
>Gene Heskett wrote:
>> I have the usual fd0, a 3.5" 1.44 drive, and fd1, a 5.25" 720k drive in
>> this machine, both are enabled in the bios with the correct types being
>> set there.
>
>A 5.25" 720k drive?! That's not a PC standard drive -- 5.25" c
On Tue, Apr 17, 2007 at 02:57:49PM -0700, David Brownell wrote:
> On Tuesday 17 April 2007 12:53 pm, David Brownell wrote:
> > On Friday 13 April 2007 8:59 am, Pavel Machek wrote:
> >
> > > ...
> > > > Assuming they all adopt that same "parallel tree" model, that seems
> > > > like a good idea. T
On Tue, 2007-04-17 at 19:58 -0700, Andrew Morton wrote:
> On Tue, 17 Apr 2007 21:19:46 -0400 Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> >
> > I've split the issues introduced by the 2.6.21-rcX write code up into 4
> > subproblems.
> >
> > The first patch is just a cleanup in order to ease re
On Tue, 17 Apr 2007 21:19:46 -0400 Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> I've split the issues introduced by the 2.6.21-rcX write code up into 4
> subproblems.
>
> The first patch is just a cleanup in order to ease review.
>
> Patch number 2 ensures that we never release the PG_writeba
Michael K. Edwards wrote:
On 4/17/07, Peter Williams <[EMAIL PROTECTED]> wrote:
The other way in which the code deviates from the original as that (for
a few years now) I no longer calculated CPU bandwidth usage directly.
I've found that the overhead is less if I keep a running average of the
si
James Morris wrote:
>This is not what the discussion is about. It's about addressing the many
>points in the FAQ posted here which are likely to cause misunderstandings,
>and then subsequent responses of a similar nature.
Thank you. Then I misunderstood, and I owe you an apology. Thank you
f
William Lee Irwin III wrote:
Peter Williams wrote:
William Lee Irwin III wrote:
I was tempted to restart from scratch given Ingo's comments, but I
reconsidered and I'll be working with your code (and the German
students' as well). If everything has to change, so be it, but it'll
still be a deri
> On Tue, 17 Apr 2007, Larry Woodman wrote:
>
> > out_of_memory() does not panic when sysctl_panic_on_oom is set
> > if constrained_alloc() does not return CONSTRAINT_NONE. Instead,
> > out_of_memory() kills the current process whenever constrained_alloc()
> > returns either CONSTRAINT_MEMORY_POL
On Wed, 18 Apr 2007, David Wagner wrote:
> These systems probably have different tradeoffs. Consequently, it seems
> to me that arguing over whether SELinux is superior to AppArmor makes
> about as much sense as arguing over whether emacs is superior to vim,
> or whether Python is superior to Per
James Morris wrote:
>On Tue, 17 Apr 2007, David Wagner wrote:
>> Maybe you'd like to confine the PHP interpreter to limit what it can do.
>> That might be a good application for something like AppArmor. You don't
>> need comprehensive information flow control for that kind of use, and
>> it would
> Peter Williams wrote:
> >William Lee Irwin III wrote:
> >>I was tempted to restart from scratch given Ingo's comments, but I
> >>reconsidered and I'll be working with your code (and the German
> >>students' as well). If everything has to change, so be it, but it'll
> >>still be a derived work. It
James Morris wrote:
>I would challenge the claim that AppArmor offers any magic bullet for
>ease of use.
There are, of course, no magic bullets for ease of use.
I would not make such a strong claim. I simply stated that it
is plausible that AppArmor might have some advantages in some
deployment
Peter Williams wrote:
William Lee Irwin III wrote:
I was tempted to restart from scratch given Ingo's comments, but I
reconsidered and I'll be working with your code (and the German
students' as well). If everything has to change, so be it, but it'll
still be a derived work. It would be ignoring
On Tue, 17 Apr 2007, David Wagner wrote:
> Maybe you'd like to confine the PHP interpreter to limit what it can do.
> That might be a good application for something like AppArmor. You don't
> need comprehensive information flow control for that kind of use, and
> it would likely just get in the w
Quoting Michael Tokarev ([EMAIL PROTECTED]):
> Hopefully not a flamewar question...
nothing wrong with asking for clarification. Though you should have
copied [EMAIL PROTECTED]
> Currently, capabilities of a process are reset during exec()
> system call. At least effective+permitted set.
>
> 1
From: Trond Myklebust <[EMAIL PROTECTED]>
Ensure that we don't release the PG_writeback lock until after the page has
either been redirtied, or queued on the nfs_inode 'commit' list.
Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
---
fs/nfs/write.c |6 +++---
1 files changed, 3 insertio
I've split the issues introduced by the 2.6.21-rcX write code up into 4
subproblems.
The first patch is just a cleanup in order to ease review.
Patch number 2 ensures that we never release the PG_writeback flag until
_after_ we've either discarded the unstable request altogether, or put it
on the
From: Trond Myklebust <[EMAIL PROTECTED]>
Redirtying a request that is already marked for commit will screw up the
accounting for NR_UNSTABLE_NFS as well as nfs_i.ncommit.
Ensure that all requests on the commit queue are labelled with the
PG_NEED_COMMIT flag, and avoid moving them onto the dirty l
From: Trond Myklebust <[EMAIL PROTECTED]>
Protect nfs_set_page_dirty() against races with nfs_inode_add_request.
Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
---
fs/nfs/write.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/fs/nfs/write.c b/fs/nf
From: Trond Myklebust <[EMAIL PROTECTED]>
Get rid of the inlined #ifdefs.
Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
---
fs/nfs/write.c | 117 --
include/linux/nfs_page.h | 30
2 files changed, 71 insertions(+), 76 de
Apparently it's not cool anymore to use SPIN/RW_LOCK_UNLOCKED.
There's some mention of this in Documentation/spinlocks.txt, but that
only talks about dynamic initialisation.
A comment in the code mentioning the preferred usage would be good IMHO.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]
On Tue, 17 Apr 2007, David Wagner wrote:
> be more usable than SELinux. Even if SELinux is more "complete"
> than AppArmor, I might still prefer ease of use over completeness
> and understandability.
I would challenge the claim that AppArmor offers any magic bullet for
ease of use. There are pl
On Tue, 2007-04-17 at 14:39 -0700, Christoph Lameter wrote:
>
> It recreates the old problem that we OOM while we still have memory
> in other parts of the system.
How, by the time we get here we have already decided we are going to
OOMkill or panic. This change just obeys sysctl_panic_on_oom
On Tue, Apr 17, 2007 at 05:48:30PM -0700, Christoph Lameter wrote:
> On Tue, 17 Apr 2007, Siddha, Suresh B wrote:
>
> > While going through the slab code, I observed that alien caches are
> > not getting resized, when user changes the slab tunables. Appended patch
> > tries to fix this. Please rev
On Tue, 17 Apr 2007, Siddha, Suresh B wrote:
> While going through the slab code, I observed that alien caches are
> not getting resized, when user changes the slab tunables. Appended patch
> tries to fix this. Please review and let me know if I missed anything.
Let it be. We have not resized the
On Tue, 17 Apr 2007, Bill Davidsen wrote:
> Rafael J. Wysocki wrote:
> > [appropriate CCs added]
> >
> > On Friday, 13 April 2007 02:33, Robert P. J. Day wrote:
> > > just something i threw together, not in final form, but it represents
> > > tossing the legacy PM stuff. at the moment, the menuco
Christoph,
While going through the slab code, I observed that alien caches are
not getting resized, when user changes the slab tunables. Appended patch
tries to fix this. Please review and let me know if I missed anything.
thanks,
suresh
---
Resize the alien caches too based on the slab tunables
On Tue, Apr 17, 2007 at 04:52:08PM -0700, Michael K. Edwards wrote:
> On 4/17/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> >The ongoing scheduler work is on a much more basic level than these
> >affairs I'm guessing you googled. When the basics work as intended it
> >will be possible to m
On Wed, Apr 18, 2007 at 07:48:55AM +0800, Antonino A. Daplas wrote:
> > When the backlight doesn't come on, for some reason, nothing else
> > runs. Capslock works, so it's at least partially alive, but even
> > doing..
> >
> > echo mem > /sys/power/state ; echo foo >/bar ; sync
> >
> > r
On 4/18/07, Jasper Spaans <[EMAIL PROTECTED]> wrote:
Might be a setting in the bios... look for something like memory hole,
memory remapping, 4G DRAM, etc.
I checked. BIOS says 4GB. No memory hole setting. But I'll play around
a bit more.
Thanks,
Jeff.
-
To unsubscribe from this list: send th
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
In shadow mode hypervisors, ptep_get_and_clear achieves the desired
purpose of keeping the shadows in sync by issuing a native_get_and_clear,
followed by a call to pte_update, which indicates the PTE has been
modified.
Direct mode hypervisors
Willy Tarreau wrote:
Hi Gene,
On Tue, Apr 17, 2007 at 12:53:56AM -0400, Gene Heskett wrote:
On Monday 16 April 2007, Ingo Molnar wrote:
this is the second release of the CFS (Completely Fair Scheduler)
patchset, against v2.6.21-rc7:
http://redhat.com/~mingo/cfs-scheduler/sched-cfs-v2.patch
Karl MacMillan wrote:
>My private ssh keys need to be protected regardless
>of the file name - it is the "bag of bits" that make it important not
>the name.
I think you picked a bad example. That's a confidentiality policy.
AppArmor can't make any guarantees about confidentiality. Neither can
S
On Tue, 2007-04-17 at 12:08 -0400, Alan Stern wrote:
> More specifically, there _is_ no way in general to ensure that a reference
> will go away when the module's cleanup routine is called, unless you are
> very careful not to pass that reference on to _anybody_. The driver core
> certainly can't
On 4/17/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
The ongoing scheduler work is on a much more basic level than these
affairs I'm guessing you googled. When the basics work as intended it
will be possible to move on to more advanced issues.
OK, let me try this in smaller words for pe
On 4/17/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
On Monday 16 April 2007 15:14, Luca Tettamanti wrote:
> Problem is that ACPI methods are not documented at all (how am I
> supposed to know that "G6T6" is the reading of the 12V rail?) while the
> datasheet of hw monitoring chips (w83627ehf in
Chris Friesen wrote:
Peter Williams wrote:
Chris Friesen wrote:
Scuse me if I jump in here, but doesn't the load balancer need some
way to figure out a) when to run, and b) which tasks to pull and
where to push them?
Yes but both of these are independent of the scheduler discipline in
force
On Mon, 2007-04-16 at 23:34 -0400, Dave Jones wrote:
> On Mon, Apr 16, 2007 at 10:26:43AM +0100, Richard Purdie wrote:
>
> > > > > > CONFIG_FB_BACKLIGHT=y
> > > > > > CONFIG_ACPI_VIDEO=n
> > > > >
> > > > > That also gets me a dead display. Backlight doesn't turn back on.
> > > >
>
On Tue, 2007-04-17 at 17:37 -0400, Dave Jones wrote:
> commit 2dec3ba8d872aa3ffbcdb8f6f8a2c0bcd44e9910 puzzles me.
>
> git-bisect just fingered it as responsible for my "backlight doesn't turn on"
> suspend/resume regression on the Thinkpad X60. I think it's lying.
>
> Why? Because afaict, driv
On Wed, Apr 18, 2007 at 09:23:42AM +1000, Peter Williams wrote:
> Matt Mackall wrote:
> >On Tue, Apr 17, 2007 at 09:01:55AM +0200, Nick Piggin wrote:
> >>On Mon, Apr 16, 2007 at 11:26:21PM -0700, William Lee Irwin III wrote:
> >>>On Mon, Apr 16, 2007 at 11:09:55PM -0700, William Lee Irwin III wrote
Andi Kleen wrote:
> Is there any movement on this?
I'm open to reasonable patches for the hooks at least. If that is done
then the actual kgdb code can be reviewed and considered eventually too.
But just having the hooks in would make it easy enough to use anyways
(no patching, just dropping
On Mon, Apr 16, 2007 at 10:35:21PM -0700, Christoph Lameter wrote:
> The flag SLAB_MUST_HWCACHE_ALIGN is
>
> 1. Never checked by SLAB at all.
>
> 2. A duplicate of SLAB_HWCACHE_ALIGN for SLUB
>
> 3. Fulfills the role of SLAB_HWCACHE_ALIGN for SLOB.
>
> The only remaining use is in sparc64 and p
On Tue, 2007-04-17 at 16:09 -0700, Crispin Cowan wrote:
> David Safford wrote:
> > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> >
>
> The meaning of a file is how other processes interpret it. Until then,
> /etc/resolv.conf is just a quaint bag of bits. What makes it special is
>
Matt Mackall wrote:
On Tue, Apr 17, 2007 at 09:01:55AM +0200, Nick Piggin wrote:
On Mon, Apr 16, 2007 at 11:26:21PM -0700, William Lee Irwin III wrote:
On Mon, Apr 16, 2007 at 11:09:55PM -0700, William Lee Irwin III wrote:
All things are not equal; they all have different properties. I like
O
On Tue, 2007-04-17 at 15:55 -0700, Crispin Cowan wrote:
> Karl MacMillan wrote:
> > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> >
> >> On Mon, 16 Apr 2007, John Johansen wrote:
> >>
> >>> Label-based security (exemplified by SELinux, and its predecessors in
> >>> MLS systems) a
Karl MacMillan wrote:
> On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
>
>> On Mon, 16 Apr 2007, John Johansen wrote:
>>
>>> Label-based security (exemplified by SELinux, and its predecessors in
>>> MLS systems) attaches security policy to the data. As the data flows
>>> through the
--- Karl MacMillan <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-04-17 at 13:19 -0700, Casey Schaufler wrote:
> > --- Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > > although this can often be done with PAM plugins, which is a standard
> way
> > > > to do this kind of thing in modern Unix & Linux OSs.
On Tue, Apr 17, 2007 at 03:59:02PM -0700, William Lee Irwin III wrote:
> On Tue, Apr 17, 2007 at 03:32:56PM -0700, William Lee Irwin III wrote:
> >> I'm already working with this as my assumed nice semantics (actually
> >> something with a specific exponential base, suggested in other emails)
> >>
David Safford wrote:
> On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
>
>> On Mon, 16 Apr 2007, John Johansen wrote:
>>
>>> Label-based security (exemplified by SELinux, and its predecessors in
>>> MLS systems) attaches security policy to the data. As the data flows
>>> through the
On Tue, Apr 17, 2007 at 04:00:53PM -0700, Michael K. Edwards wrote:
> Works, that is, right up until you add nonlinear interactions with CPU
> speed scaling. From my perspective as an embedded platform
> integrator, clock/voltage scaling is the elephant in the scheduler's
> living room. Patch in
On 4/17/07, Peter Williams <[EMAIL PROTECTED]> wrote:
The other way in which the code deviates from the original as that (for
a few years now) I no longer calculated CPU bandwidth usage directly.
I've found that the overhead is less if I keep a running average of the
size of a tasks CPU bursts an
On Tue, Apr 17, 2007 at 03:32:56PM -0700, William Lee Irwin III wrote:
>> I'm already working with this as my assumed nice semantics (actually
>> something with a specific exponential base, suggested in other emails)
>> until others start saying they want something different and agree.
On Tue, Apr
On Tue, Apr 17, 2007 at 03:32:56PM -0700, William Lee Irwin III wrote:
> On Tue, Apr 17, 2007 at 11:24:22AM +0200, Ingo Molnar wrote:
> >> yeah. If you could come up with a sane definition that also translates
> >> into low overhead on the algorithm side that would be great!
>
> On Tue, Apr 17, 2
1 - 100 of 431 matches
Mail list logo
