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
> -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
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
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
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
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
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
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.
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
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
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
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
>
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
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
> 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
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
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
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
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
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
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?
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
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
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
> >
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.
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
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
>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
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
> >
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
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
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
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"
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.
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
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
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
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
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
> 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
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
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
> 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.
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
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
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.
>
>
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
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
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
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
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
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
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
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
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
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
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
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
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
> >
> >
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
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
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
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
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,
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
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
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
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)
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
--- 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
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
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,
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,
On Tuesday 17 April 2007 18:12:17 David Lang wrote:
> On Tue, 17 Apr 2007, Daniel Hazelton wrote:
> > On Tuesday 17 April 2007 15:58:09 Tomasz Kłoczko wrote:
> >> On Tue, 17 Apr 2007, Daniel Hazelton wrote:
> >> [..]
> >>
> Why on discussion about switching to GPL v3 Linux code this argument
On Tue, 17 Apr 2007, Daniel Hazelton wrote:
On Tuesday 17 April 2007 15:58:09 Tomasz Kłoczko wrote:
On Tue, 17 Apr 2007, Daniel Hazelton wrote:
[..]
Why on discussion about switching to GPL v3 Linux code this argument was
allways taken as "piece of cake". Why in case switching to another
On Wed, 2007-04-18 at 02:01 +0900, OGAWA Hirofumi wrote:
> Hi,
>
> I've got the following message today. Probably, it happened on heavy load.
>
> NFS: desynchronized value of nfs_i.ncommit.
> NFS: desynchronized value of nfs_i.ncommit.
> NFS: desynchronized value of nfs_i.ncommit.
> NFS:
> After the discussions that took place back around the time of the release of
> the first draft of GPLv3 it was decided to lock Linux to *ONLY* GPLv2
This is not accurate. As far back as I can easily check, the kernel's
COPYING file has said:
Also note that the only valid version of the
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, 2007 at 05:08:09PM -0500, Matt Mackall wrote:
> How's this:
> If you're running
On Wed, 2007-04-18 at 00:12 +0200, Andi Kleen wrote:
> > The vast majority of applications are not
> > modified to be SELinux aware - only a small handful of security aware
> > applications are modified.
>
> All applications that can edit /etc/resolv.conf? That's nearly
> everything. You
On Tue, 2007-04-17 at 20:10 +0200, Andi Kleen wrote:
> On Tue, Apr 17, 2007 at 01:47:39PM -0400, James Morris wrote:
> > Normal applications need zero modification under SELinux.
> >
> > Some applications which manage security may need to be made SELinux-aware,
>
> Anything that can touch
On Tuesday 17 April 2007 3:12 pm, Bill Davidsen wrote:
>
> One reason was that there are (were?) a number of machines which only
> powered down properly using apm. It was discussed as part of shutting
> down after power failure when your UPS is running out of power.
At least the notification
On Tue, 17 Apr 2007, William Lee Irwin III wrote:
> On Tue, Apr 17, 2007 at 09:01:55AM +0200, Nick Piggin wrote:
> > Latency. Given N tasks in the system, an arbitrary task should get
> > onto the CPU in a bounded amount of time (excluding events like freak
> > IRQ holdoffs and such, obviously --
On Tue, Apr 17, 2007 at 11:24:22AM +0200, Ingo Molnar wrote:
>
> * William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>
> > [...] Also rest assured that the tone of the critique is not hostile,
> > and wasn't meant to sound that way.
>
> ok :) (And i guess i was too touchy - sorry about coming
1 - 100 of 877 matches
Mail list logo
