On Tue, Jul 10, 2007 at 10:29:42PM -0700, Andrew Morton wrote:
> I'm inclined to take the cautious route here - I don't think people will be
> dying for the CFS thingy (which I didn't even know about?) in .23, and it's
> rather a lot of infrastructure to add for a CPU scheduler configurator
>
Ray Lee wrote:
On 7/10/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Matthew Hawkins wrote:
> On 7/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Anyhow with swap prefetch, applications that may have been sitting
> there idle for a while become responsive in the single-digit seconds
> rather
Which is your platform ?
Which processor?
If you want to use physical address directly, then disable MMU. That
is not possible in linux.
Nobin
On 7/11/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Thanks for the quick reply. But I
On Tue, 10 Jul 2007, Joel Becker wrote:
> On Wed, Jul 11, 2007 at 03:40:22AM +0530, Satyam Sharma wrote:
> > IMHO something that mentions /proc/sys/kernel/printk would be better.
> >
> > You don't need to have built with SysRq support for that, it's clearly
> > more flexible than the
On Sun, 01 Jul 2007 03:38:18 -0400 Mingming Cao <[EMAIL PROTECTED]> wrote:
> >From [EMAIL PROTECTED] Thu May 17 17:21:08 2007
> Hi,
>
> I have rebased this patch to 2.6.22-rc1 so that it can be added to the
> ext4 patch queue. It has been tested by creating more than 65000 subdirs
> and then
On Tue, 10 Jul 2007 16:30:25 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sun, 01 Jul 2007 03:36:48 -0400
> Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > > On Jun 07, 2007 23:45 -0500, Jose R. Santos wrote:
> > > > The jbd2-debug file used to be located in /proc/sys/fs/jbd2-debug, but
>
On Wed, 11 Jul 2007 10:25:16 +0530 Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 10, 2007 at 11:53:19AM -0700, Andrew Morton wrote:
> > On Tue, 10 Jul 2007 11:34:38 -0700
> > "Paul Menage" <[EMAIL PROTECTED]> wrote:
> >
> > > Andrew, how about we merge enough of the container
On Tue, 2007-07-10 at 21:22 -0700, Andrew Morton wrote:
> On Tue, 10 Jul 2007 20:19:16 -0400 Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-07-10 at 18:22 -0700, Andrew Morton wrote:
> > > On Tue, 10 Jul 2007 18:09:40 -0400 Mingming Cao <[EMAIL PROTECTED]> wrote:
> > >
> > > > On
On Tue, 10 Jul 2007 22:12:24 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
> But myself, nor any other developers, are going to review your work
> any faster if you do things like try to slip things in behind the
> maintainer's back as you attempted to do yesterday by asking Andrew to
> put
On Wed, 11 Jul 2007 15:05:27 +1000 Neil Brown <[EMAIL PROTECTED]> wrote:
>
> It just occurred to me:
>
> If i_version is 64bit, then knfsd would need to be careful when
> reading it on a 32bit host. What are the locking rules?
>
> Presumably it is only updated under i_mutex protection, but
On Tue, 2007-07-10 at 21:42 -0700, Andrew Morton wrote:
> On Tue, 10 Jul 2007 23:21:49 -0400 "Cédric Augonnet" <[EMAIL PROTECTED]>
> wrote:
>
> > 2007/7/10, Andrew Morton <[EMAIL PROTECTED]>:
> >
> > Hi all,
> >
> > > > + size = sizeof(struct transaction_stats_s);
> > > > + s->stats =
Matthew Hawkins wrote:
On 7/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
Anyhow with swap prefetch, applications that may have been sitting
there idle for a while become responsive in the single-digit seconds
rather than double-digit or worse. The same goes for a morning wakeup
(ie after
On Tue, 10 Jul 2007 22:09:08 -0400 Mingming Cao <[EMAIL PROTECTED]> wrote:
> David Chinneer pointed that we need to journal the version number
> updates together with the operations that causes the change of the inode
> version number, in order to survive server crashes so clients won't see
> the
Just to make it clear Miklos.
I have seen your patch as has everyone else.
But myself, nor any other developers, are going to review your work
any faster if you do things like try to slip things in behind the
maintainer's back as you attempted to do yesterday by asking Andrew to
put your
On Wed, 2007-07-11 at 13:21 +1000, Neil Brown wrote:
> On Tuesday July 10, [EMAIL PROTECTED] wrote:
> >
> > Yes, thanks. It doesn't actually tell us why we want to implement
> > this attribute and it doesn't tell us what the implications of failing
> > to do so are, but I guess we can take that
Hi,
* Li, Tong N ([EMAIL PROTECTED]) wrote:
> Mathieu,
>
> > cycles_per_iter = 0.0;
> > for (i=0; i > time1 = get_cycles();
> > for (j = 0; j < NR_ITER; j++) {
> > testval = [random() % ARRAY_SIZE];
> > }
> > time2 =
It just occurred to me:
If i_version is 64bit, then knfsd would need to be careful when
reading it on a 32bit host. What are the locking rules?
Presumably it is only updated under i_mutex protection, but having to
get i_mutex to read it would seem a little heavy handed.
Should it use a
Alan Stern wrote:
>> Please also note that currently dev->sem does not protect against adding
>> children. It says it does in the comment on the definition of the field
>> but it's never acquired during device_add().
>
> That's why we need the rwsem.
Alright, there's our confusion. I thought
On Tue, 2007-07-10 at 16:30 -0700, Andrew Morton wrote:
> On Sun, 01 Jul 2007 03:36:56 -0400
> Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > This patch is a spinoff of the old nanosecond patches.
>
> I don't know what the "old nanosecond patches" are. A link to a suitable
> changlog for those
On Wed, Jul 11, 2007 at 12:10:34PM +1000, Stephen Rothwell wrote:
> On Wed, 11 Jul 2007 01:50:00 +0530 "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
> >
> > --- linux-2.6.22.orig/arch/x86_64/ia32/sys_ia32.c
> > +++ linux-2.6.22/arch/x86_64/ia32/sys_ia32.c
> > @@ -879,3 +879,11 @@ asmlinkage long
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> On Fri, Jul 06, 2007 at 10:41:44AM -0400, Mathieu Desnoyers wrote:
> > I haven't thought about making it the default for kernel space
> > preemption, but yes, it would make sense.
>
> Now it's too late -- getcpu() has infected the kernel everywhere.
> It
[4/9 (updated)] netconsole: Add some useful tips to documentation
Add some useful general-purpose tips. Also suggest solution for the frequent
problem of console_loglevel set too low numerically (i.e. for high priority
messages only) on the sender.
Cc: Matt Mackall <[EMAIL PROTECTED]>
Cc: Jesper
On Tue, Jul 10, 2007 at 07:26:10PM -0700, Christoph Lameter wrote:
> On Wed, 11 Jul 2007, Nick Piggin wrote:
>
> > BTW. some advanced congestion algorithms like HBO may find these ticket
> > locks useful because you can see immediately how many CPUs are contending
> > the lock, and spinners know
Hi,
Still as an RFC, here is an updated version of the migration handling
code in sched.c that supports migrate_disable()/migrate_enable().
I have taken care of the comments I received, thanks. I switched to
migrate_enable/disable following Matt Mackall's comments. He also
suggested to create,
Dave Young wrote:
Hi, randy
how about remove the spec links in the header files as well.
Subject:
Remove document links in hpet header files.
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
Agreed. Acked-by: Randy Dunlap <[EMAIL PROTECTED]>
---
include/asm-i386/hpet.h |6 --
H. Peter Anvin wrote:
> Al Boldi wrote:
> > Try this "[PATCH] initramfs: Allow rootfs to use tmpfs instead of
> > ramfs".
> >
> > It's trivial and should be in mainline.
>
> Simple, yes, trivial, no.
>
> It should be pushed to -mm before mainline to give it some smokeout time.
Great, maybe
On Tue, Jul 10, 2007 at 11:53:19AM -0700, Andrew Morton wrote:
> On Tue, 10 Jul 2007 11:34:38 -0700
> "Paul Menage" <[EMAIL PROTECTED]> wrote:
>
> > Andrew, how about we merge enough of the container framework to
> > support CFS? Bits we could leave out for now include container_clone()
> >
On Tue, 10 Jul 2007 23:21:49 -0400 "Cédric Augonnet" <[EMAIL PROTECTED]> wrote:
> 2007/7/10, Andrew Morton <[EMAIL PROTECTED]>:
>
> Hi all,
>
> > > + size = sizeof(struct transaction_stats_s);
> > > + s->stats = kmalloc(size, GFP_KERNEL);
> > > + if (s == NULL) {
> > > +
On Tue, Jul 10, 2007 at 11:21:49PM -0400, Cédric Augonnet wrote:
> 2007/7/10, Andrew Morton <[EMAIL PROTECTED]>:
>
> Hi all,
>
> >> + size = sizeof(struct transaction_stats_s);
> >> + s->stats = kmalloc(size, GFP_KERNEL);
> >> + if (s == NULL) {
^
> >> +
On Wed, Jul 11, 2007 at 03:47:09AM +0530, Satyam Sharma wrote:
> Hmm, I put it in there because I expected that the user must have had
> at least one target configured (added to target_list) if he's got the
> module loaded/built-in (and netconsole registered), which is when this
> function would
On Tue, 10 Jul 2007 20:19:16 -0400 Mingming Cao <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-07-10 at 18:22 -0700, Andrew Morton wrote:
> > On Tue, 10 Jul 2007 18:09:40 -0400 Mingming Cao <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 2007-07-10 at 16:30 -0700, Andrew Morton wrote:
> > > > On Sun, 01
On Wed, Jul 11, 2007 at 03:40:22AM +0530, Satyam Sharma wrote:
> IMHO something that mentions /proc/sys/kernel/printk would be better.
>
> You don't need to have built with SysRq support for that, it's clearly
> more flexible than the ignore_loglevel option and wouldn't require a
> reboot either.
Jeremy Fitzhardinge wrote:
> Jeremy Maitin-Shepard wrote:
> > In
> > addition, I recall that the Linux boot procedure on x86 and on some
> > other platforms necessarily uses certain low-address memory, like the
> > first 640K, which must be backed up regardless.
>
> Well, the traditional
Hi.
William Tambe wrote:
I understand your concern. But since I am working on a dynamic memory
management code that I wish to use with other projects that I have, I
didn't find appropriate to use shm_open.
Could you please provide a detailed list of the
problems you have with shm_open? If
Hi,
On Tue, 10 Jul 2007, Duane Griffin wrote:
> On 10/07/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> > + /* Avoid taking lock and disabling interrupts unnecessarily */
> > + if (unlikely(list_empty(_list)))
> > + return;
>
> Is the unlikely a good idea here? Not
Hi Jesper,
On Tue, 10 Jul 2007, Jesper Juhl wrote:
> On Tuesday 10 July 2007 11:41:43 Matt Mackall wrote:
> > On Tue, Jul 10, 2007 at 02:49:41PM +0530, Satyam Sharma wrote:
> > > From: Satyam Sharma <[EMAIL PROTECTED]>
> > >
> > > [4/9] netconsole: Add some useful tips to documentation
> > >
> >
On Tue, 10 Jul 2007, Andrew Morton wrote:
On Wed, 11 Jul 2007 11:02:56 +1000 "Matthew Hawkins" <[EMAIL PROTECTED]> wrote:
We all know swap prefetch has been tested out the wazoo since Moses was a
little boy, is compile-time and runtime selectable, and gives an important
and quantifiable
Ira Snyder <[EMAIL PROTECTED]> writes:
>> Always interested. Please provide us more details on your usage and
>> testing of that code. Amount of memory, workload, observed results,
>> etc?
>>
>
> I often leave long compiles running overnight (I'm a gentoo user). I
> always have the desktop
On Tue, Jul 10, 2007 at 05:35:13PM -0400, Mingming Cao wrote:
>
> Sorry about this. I was using version 0.04. The latest one I can find
> for now is 0.05(searching lkml), but it didn't catch this codling style
> bug either. I appreciate if anyone can point me the version 0.07, thanks
It's
Piotr wrote:
Hello i have a problem with my ASUS p5b mobo, i am a gentoo user and i'm
getting this error while booting my system from newest gentoo-sources
2.6.22 (this also happens on earlier ver. of kernel) i get this message:
"PCI: BIOS Bug: MCFG area at f000 is not E820-reserved
PCI:
On Wed, 2007-07-11 at 13:21 +1000, Neil Brown wrote:
> On Tuesday July 10, [EMAIL PROTECTED] wrote:
> >
> > Yes, thanks. It doesn't actually tell us why we want to implement
> > this attribute and it doesn't tell us what the implications of failing
> > to do so are, but I guess we can take that
Hi, randy
how about remove the spec links in the header files as well.
Subject:
Remove document links in hpet header files.
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
include/asm-i386/hpet.h |6 --
include/asm-x86_64/hpet.h |6 --
2 files changed, 12 deletions(-)
diff
On Tuesday July 10, [EMAIL PROTECTED] wrote:
>
> Yes, thanks. It doesn't actually tell us why we want to implement
> this attribute and it doesn't tell us what the implications of failing
> to do so are, but I guess we can take that on trust from the NFS guys.
You would like to think so, but
2007/7/10, Andrew Morton <[EMAIL PROTECTED]>:
Hi all,
> + size = sizeof(struct transaction_stats_s);
> + s->stats = kmalloc(size, GFP_KERNEL);
> + if (s == NULL) {
> + kfree(s);
> + return -EIO;
ENOMEM
I'm sorry if i missed some point, but i just don't
On Tue, 2007-07-10 at 18:22 -0700, Andrew Morton wrote:
> On Tue, 10 Jul 2007 18:09:40 -0400 Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-07-10 at 16:30 -0700, Andrew Morton wrote:
> > > On Sun, 01 Jul 2007 03:37:04 -0400
> > > Mingming Cao <[EMAIL PROTECTED]> wrote:
> > >
> > > >
On Tue, Jul 10, 2007 at 12:11:45PM -0500, Dave McCracken wrote:
> On Tuesday 10 July 2007, Nick Piggin wrote:
> > On Tue, Jul 10, 2007 at 09:29:45AM -0500, Dave McCracken wrote:
> > > I find myself wondering what "sufficiently convincing noises" are. I
> > > think we can all agree that in the
On Tue, 10 Jul 2007 18:14:19 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 11 Jul 2007 11:02:56 +1000 "Matthew Hawkins" <[EMAIL PROTECTED]>
> wrote:
>
> > We all know swap prefetch has been tested out the wazoo since Moses was a
> > little boy, is compile-time and runtime selectable,
On 7/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Wed, 11 Jul 2007 11:02:56 +1000 "Matthew Hawkins" <[EMAIL PROTECTED]> wrote:
Always interested. Please provide us more details on your usage and
testing of that code. Amount of memory, workload, observed results,
etc?
My usual
Ric Wheeler wrote:
>> Don't those thingies usually have NV cache or backed by battery such
>> that ORDERED_DRAIN is enough?
>
> All of the high end arrays have non-volatile cache (read, on power loss,
> it is a promise that it will get all of your data out to permanent
> storage). You don't need
[EMAIL PROTECTED] wrote:
> On Tue, 10 Jul 2007 14:39:41 EDT, Ric Wheeler said:
>
>> All of the high end arrays have non-volatile cache (read, on power loss, it
>> is a
>> promise that it will get all of your data out to permanent storage). You
>> don't
>> need to ask this kind of array to
On Wed, 11 Jul 2007 10:04:17 + Dave Young wrote:
> The specification link in hpet document is broken.
OK. Sadly it's a moving target.
Thanks.
> Signed-off-by: Dave Young <[EMAIL PROTECTED]>
>
> ---
> Documentation/hpet.txt |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
On Sun, 01 Jul 2007 03:38:10 -0400 Mingming Cao <[EMAIL PROTECTED]> wrote:
> [PATCH] jbd2 stats through procfs
>
> The patch below updates the jbd stats patch to 2.6.20/jbd2.
> The initial patch was posted by Alex Tomas in December 2005
> (http://marc.info/?l=linux-ext4=113538565128617=2).
> It
On Wed, 11 Jul 2007, Nick Piggin wrote:
> BTW. some advanced congestion algorithms like HBO may find these ticket
> locks useful because you can see immediately how many CPUs are contending
> the lock, and spinners know how many CPUs are in front of them. That info
> could be fed into the spin
On Wed, 11 Jul 2007 01:50:00 +0530 "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
>
> --- linux-2.6.22.orig/arch/x86_64/ia32/sys_ia32.c
> +++ linux-2.6.22/arch/x86_64/ia32/sys_ia32.c
> @@ -879,3 +879,11 @@ asmlinkage long sys32_fadvise64(int fd,
> return sys_fadvise64_64(fd, ((u64)offset_hi <<
On Tue, Jul 10, 2007 at 06:37:42PM -0700, Christoph Lameter wrote:
> On Tue, 10 Jul 2007, Matt Mackall wrote:
>
> > You're delusional.
>
> Git log says otherwise:
>
> git log --pretty=short mm/slob.c
A dozen trivial cleanups do not make you maintainer. Otherwise we'd
all be sending our
On Tue, Jul 10, 2007 at 01:52:47PM -0700, Christoph Lameter wrote:
> On Sun, 8 Jul 2007, Andi Kleen wrote:
>
> > I would say the main drawback of switchable and queued locks
> > would be also that they require a larger spinlock_t thus increasing
> > cache usage
>
> Right. Zoran Radovic has
On Tue, 2007-07-10 at 20:44 +0200, Jan Dittmer wrote:
> Mike Frysinger wrote:
> > On 7/4/07, Jan Dittmer <[EMAIL PROTECTED]> wrote:
> >> Mike Frysinger wrote:
> >>> On 7/3/07, Jan Dittmer <[EMAIL PROTECTED]> wrote:
> Bryan Wu wrote:
> > Jie's patch is required because we will release our
The specification link in hpet document is broken.
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
Documentation/hpet.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -pur linux/Documentation/hpet.txt linux.new/Documentation/hpet.txt
--- linux/Documentation/hpet.txt
This is an update to iproute2 utilities including bug fixes and features
related to 2.6.22 kernel.
This package tries to be source compatible across releases.
The same source should build on older systems, but obviously the
newer kernel features won't be available.
It can be downloaded from:
On 7/10/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Wed, 11 Jul 2007 11:02:56 +1000 "Matthew Hawkins" <[EMAIL PROTECTED]> wrote:
> We all know swap prefetch has been tested out the wazoo since Moses was a
> little boy, is compile-time and runtime selectable, and gives an important
> and
On Tue, 10 Jul 2007 23:00:59 GMT Linux Kernel Mailing List
wrote:
> +static int shmem_readpage(struct file *file, struct page *page)
> +{
> + struct inode *inode = page->mapping->host;
> + int error = shmem_getpage(inode, page->index, , SGP_CACHE, NULL);
> + unlock_page(page);
> +
I refitted the 4 patches you posted to a 22-rc6-mm1 kernel, and tried it on
my Dell Latitude D820 laptop, using the libata driver for the disk and DVD.
I got this:
[0.702000] scsi0 : ata_piix
[0.702000] scsi1 : ata_piix
[0.702000] ata1: SATA max UDMA/133 cmd 0x000101f0 ctl
On Tue, 10 Jul 2007, Matt Mackall wrote:
> You're delusional.
Git log says otherwise:
git log --pretty=short mm/slob.c
Author: Christoph Lameter <[EMAIL PROTECTED]>
Remove SLAB_CTOR_CONSTRUCTOR
Author: Christoph Lameter <[EMAIL PROTECTED]>
Slab allocators: Drop support for
On Wed, 11 Jul 2007 06:18:20 +1000, Amit K. Arora
<[EMAIL PROTECTED]> wrote:
Following is the modified version of the manpage originally submitted by
David Chinner. Please use `nroff -man fallocate.2 | less` to view.
A few more touch-ups attached.
Regards,
Barry.
fallocate.2
Description:
On Tue, 10 Jul 2007, Douglas Gilbert wrote:
Kai Makisara wrote:
I have done some more debugging on this one. An easy way to reproduce
the
The log shows that the sense data returned by the commands differ: with
2.6.22 the bytes 4f and 2c (tf.lbam and tf.lbah) are not returned. Both
of
On Tue, 10 Jul 2007 18:09:40 -0400 Mingming Cao <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-07-10 at 16:30 -0700, Andrew Morton wrote:
> > On Sun, 01 Jul 2007 03:37:04 -0400
> > Mingming Cao <[EMAIL PROTECTED]> wrote:
> >
> > > This patch converts the 32-bit i_version in the generic inode to a
Hi,
On Tuesday 10 July 2007, Lennart Sorensen wrote:
> On Sun, Jul 01, 2007 at 09:24:41PM +0200, Rodolfo Giometti wrote:
> > struct pps_timedata_s {
> >__32 sec;
> >__32 nsec;
> > }
> >
> > Ok? I think 32 bits are enought for keeping seconds... :)
>
> You want to
On Fri, Jul 06, 2007 at 12:01:59PM +0400, Pavel Emelianov wrote:
> This is "submition for inclusion" of hierarchical, not kconfig
> configurable, zero overheaded ;) pid namespaces.
How big is it?
Do I want it on my cell phone or on my wireless router?
--
Mathematics is the supreme nostalgia of
On Wed, 11 Jul 2007 11:02:56 +1000 "Matthew Hawkins" <[EMAIL PROTECTED]> wrote:
> We all know swap prefetch has been tested out the wazoo since Moses was a
> little boy, is compile-time and runtime selectable, and gives an important
> and quantifiable performance increase to desktop systems.
Mathieu Desnoyers wrote:
* Matt Mackall ([EMAIL PROTECTED]) wrote:
On Wed, Jul 11, 2007 at 10:02:23AM +1000, Nick Piggin wrote:
I like this patch a lot. Even if we don't add the underlying mechanism
right now, adding migration_disable as an alias for preempt_disable
will much better document
Mikael Pettersson wrote:
This patch enables hotplugging of SATA devices in the
sata_promise driver. It's been tested successfully on
both first- and second-generation Promise SATA chips:
SATA150 TX2plus, SATAII150 TX2plus, SATAII150 TX4,
SATA300 TX2plus, and SATA300 TX4.
The only quirk I've
Alan Cox wrote:
If you are using a SiS controller and the BIOS didn't set it up then the
FIFO may be left active when we try and set up the CD. Not convinced this
matters but I'd prefer to be safe
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
applied
-
To unsubscribe from this list: send the
On Fri, Jul 06, 2007 at 03:19:50AM -0400, David Woodhouse wrote:
> On Fri, 2007-07-06 at 00:08 -0700, Andrew Morton wrote:
> > On Fri, 06 Jul 2007 03:01:03 -0400 David Woodhouse <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Reject all legacy 8-bit character sets and allow only ASCII or UTF-8 to
> > >
From: Anton Salikhmetov <[EMAIL PROTECTED]>
According to the POSIX standard, multiple real-time signals
pending to a process should be delivered in a strict order.
Specifically, the lowest-numbered signal should be delivered
first and multiple occurrences of signals with the same number
should be
On Tue, 2007-07-10 at 16:30 -0700, Andrew Morton wrote:
> On Sun, 01 Jul 2007 03:37:04 -0400
> Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > This patch converts the 32-bit i_version in the generic inode to a 64-bit
> > i_version field.
> >
>
> That's obvious from the patch. But what was the
* Matt Mackall ([EMAIL PROTECTED]) wrote:
> On Wed, Jul 11, 2007 at 10:02:23AM +1000, Nick Piggin wrote:
> > >I like this patch a lot. Even if we don't add the underlying mechanism
> > >right now, adding migration_disable as an alias for preempt_disable
> > >will much better document quite a
Andrew Morton writes:
> On Wed, 11 Jul 2007 09:27:40 +1000
> Paul Mackerras <[EMAIL PROTECTED]> wrote:
>
> > We did come up with an order that worked for everybody, but that
> > discussion seemed to get totally ignored by the ext4 developers.
>
> It was a long discussion.
>
> Can someone
Al Boldi wrote:
>
> Try this "[PATCH] initramfs: Allow rootfs to use tmpfs instead of ramfs".
>
> It's trivial and should be in mainline.
>
Simple, yes, trivial, no.
It should be pushed to -mm before mainline to give it some smokeout time.
-hpa
-
To unsubscribe from this list: send
On Wed, Jul 11, 2007 at 10:02:23AM +1000, Nick Piggin wrote:
> >I like this patch a lot. Even if we don't add the underlying mechanism
> >right now, adding migration_disable as an alias for preempt_disable
> >will much better document quite a number of the users.
>
> I'd have no problem with
On Tue, 2007-07-10 at 16:30 -0700, Andrew Morton wrote:
> On Sun, 01 Jul 2007 03:36:01 -0400
> Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > Turn on extents feature by default in ext4 filesystem. User could use
> > -o noextents to turn it off.
> >
>
> Oh, there you go.
>
> >
> > Index:
COWed devices can't handle more than 32 (64 on x86_64) sectors in one
request due to the size of the bitmap being carried around in the
io_thread_req.
Enforce that by telling the block layer not to put too many sectors in
requests to COWed devices.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
Add some exports for hostfs that are required after Alberto Bertogli's
fixes for accessing unlinked host files.
Also did some style cleanups while I was here.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/os-Linux/user_syms.c | 20
1 file changed, 8
Hello i have a problem with my ASUS p5b mobo, i am a gentoo user and i'm
getting this error while booting my system from newest gentoo-sources
2.6.22 (this also happens on earlier ver. of kernel) i get this message:
"PCI: BIOS Bug: MCFG area at f000 is not E820-reserved
PCI: Not using
On Wed, 11 Jul 2007 01:12:53 +0200, Stefan Richter said:
> Adrian Bunk wrote:
> > On Tue, Jul 10, 2007 at 03:39:51PM -0400, [EMAIL PROTECTED] wrote:
> >> What the Rest Of The World could probably use is if some kind soul were to
> >> go
> >> through and build a .21->.22 document that lists all
Adrian Bunk wrote:
> On Tue, Jul 10, 2007 at 01:42:48PM -0700, H. Peter Anvin wrote:
>> Segher Boessenkool wrote:
>>> Well at least with -fno-toplevel-reorder it is guaranteed
>>> to work (not the same thing as "is working", heh, but fairly
>>> close).
>>>
>>> It seems to me GCC should grow an
Pawel Dziepak wrote:
> On 7/10/07, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
>> > The alternative, of course, is to compile to an .s file and insert
>> > .code16gcc into the .s file. This makes the Makefile uglier, but
>> > would
>> > be more resilient against oddball gcc changes.
>>
>> This
On Wed, 11 Jul 2007 09:27:40 +1000
Paul Mackerras <[EMAIL PROTECTED]> wrote:
> We did come up with an order that worked for everybody, but that
> discussion seemed to get totally ignored by the ext4 developers.
It was a long discussion.
Can someone please remind us what the signature of the
This scales with the number of processors since there is one
decrementer per core (is it per thread on SMT chips?
I don't know).
One per core.
No, each thread has its own decrementer, but the timebase is shared.
Argh, of course you're right, I'm reading the wrong ISA
version again. Sorry.
On Wed, 11 Jul 2007, Adrian Bunk wrote:
On Tue, Jul 10, 2007 at 03:39:51PM -0400, [EMAIL PROTECTED] wrote:
On Sun, 08 Jul 2007 16:52:52 PDT, Linus Torvalds said:
The full changelog since 2.6.21 also got uploaded, but quite frankly, I
wonder if anybody uses those things? I've been uploading
On 7/10/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
Satyam Sharma wrote:
> On 7/10/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
>> Satyam Sharma wrote:
>> >
>> >
>> > On 7/9/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
>> >> [...]
>> >> on_each_cpu() was imho always a mistake. It would have been better
Matt Mackall wrote:
On Fri, Jul 06, 2007 at 04:12:10PM +1000, Nick Piggin wrote:
Mathieu Desnoyers wrote:
Thread Migration Preemption
This patch adds the ability to protect critical sections from migration to
another CPU without disabling preemption.
This will be useful to minimize the
these are revised or new patch with numa_node in struct device in addition to
andrew already sent to andi
x86_64-get-mp_bus_to_node-as-early.patch
it will make all pci_dev->dev.numa_node correctly.
still in -mm, and andrew will re-review for 2.6.23
dma-make-dma-pool-to-use-kmalloc_node.patch
[PATCH 2/5] net: use numa_node in net_devcice->dev instead of parent
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 27cfe5f..005cc1c 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -217,7 +217,7 @@ nodata:
struct sk_buff
[PATCH 5/5] dma: use dev_to_node to get node for device in dma_alloc_pages
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86_64/kernel/pci-dma.c b/arch/x86_64/kernel/pci-dma.c
index 9f80aad..6dbf1c9 100644
--- a/arch/x86_64/kernel/pci-dma.c
+++ b/arch/x86_64/kernel/pci-dma.c
@@
[PATCH] serial: do not add port that is not initialized
if the port is not initialized with correct iobase, and membase, we don't
need to add that port.
for x86, when pnpacpi is enabled, we will not get extra ttyS1/ttyS2/ttyS3 in
/sys/devices/platform/serial8250/tty
Sign-off-by: Yinghai Lu
[PATCH 4/5] net: show numa_node for net_device in /sys
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 5c19b06..45b87a5 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -230,6 +230,14 @@ static ssize_t
[PATCH 1/5] try parent numa_node at first before using default
For pci_device, pcibios_scan_root and pci_scan_root will call pci_device_add.
pci_device_add will call device_initialize and set_dev_node(>dev,
pcibus_to_node(bus)).
other device such as netdev, and usb_device, set_dev_node is never
[PATCH 3/5] net: make forcedeth to use kmalloc_node and netdev_alloc_skb for
skb allocation
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 42ba1c0..3f4f559 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@
On Wed, Jul 11, 2007 at 01:12:53AM +0200, Stefan Richter wrote:
> Adrian Bunk wrote:
> > On Tue, Jul 10, 2007 at 03:39:51PM -0400, [EMAIL PROTECTED] wrote:
> >> What the Rest Of The World could probably use is if some kind soul were to
> >> go
> >> through and build a .21->.22 document that lists
Segher Boessenkool writes:
> > This scales with the number of processors since there is one
> > decrementer per core (is it per thread on SMT chips?
> > I don't know).
>
> One per core.
No, each thread has its own decrementer, but the timebase is shared.
Paul.
-
To unsubscribe from this list:
1 - 100 of 1121 matches
Mail list logo
