* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Your compiler generates
>
> movl-16(%ebp),%edx
> movl(%edx),%edi /* this is _totally_ bogus! */
> incl%edx
> movl%edx,-16(%ebp)
> movl%edi,%ecx
> testb %cl,%cl
> je ...
On Wed, 3 Oct 2007, Linus Torvalds wrote:
>
> - the bug happens on this:
>
> char c = *p++;
>
> - which has been compiled into
>
> 8b 3a mov(%edx),%edi
Btw, this definitely doesn't happen for me, either on x86-64 or plain x86.
The x86 thing I tested was Fedora 8
When shrinking the size of the hugetlb pool via the nr_hugepages sysctl, we
are careful to keep enough pages around to satisfy reservations. But the
calculation is flawed for the following scenario:
Action Pool Counters (Total, Free, Resv)
==
> and btw, there is no question what-so-ever about whether your compiler
> might be doing a legal optimization - the compiler really is wrong, and is
Pedant: valid. Almost all optimizations are legal, nobody has yet written
laws about compilers. Sorry but I'm forever fixing misuse of the word
On Wed, October 3, 2007 7:18 am, Paul Mundt wrote:
> On Tue, Oct 02, 2007 at 10:09:27PM +0100, Adrian McMenamin wrote:
>> Fix SH DMAC code to correctly handle PVR2 cascade DMA.
>>
>> This updates http://lkml.org/lkml/2007/10/2/276
>>
>> (I decided it was better to have the true size of the
El Tue, 2 Oct 2007 16:32:00 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]>
escribió:
> Heh. The "remove sk98lin driver" bullet is sadly wrong. We had to
> reinstate it because it supported some cards that the skge driver doesn't
> handle.
Thanks, fixed
-
To unsubscribe from this list: send
On Wed, 3 Oct 2007, Nick Piggin wrote:
>
> I don't know if Linus actually disliked the patch itself, or disliked
> my (maybe confusingly worded) rationale?
Yes. I'd happily accept the patch, but I'd want it clarified and made
obvious what the problem was - and it wasn't the zero page itself,
On 10/1/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On 9/30/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> > On 9/30/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
> > > Torsten Kaiser wrote:
> To make that comment "cmd part of the output was always the same" more
> clear: I did not only mean that
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> - What are these apparent 'exec notifications' that are provided to
>user space that the following mentions - I cannot find any other
>mention of them:
>
> With the ability to classify tasks differently for different
>
On Wed, 3 Oct 2007 15:26:01 +0100
Al Viro <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 04:08:42PM +0200, Ingo Molnar wrote:
> > > Charming... So we get d_path() either returning junk or we get
> > > something that isn't NUL-terminated. Which one it is? I.e. what
> > > does p look like
On Wed, 3 Oct 2007, Ingo Molnar wrote:
>
> hm, i just triggered the procfs crash below with -rc9 on a testbox.
You have a terminally buggy piece of shit compiler.
Lookie here:
- the bug happens on this:
char c = *p++;
- which has been compiled into
8b 3a mov
Hello,
someone is working on this device?
http://www.oxsemi.com/products/usb/OXU210HP.html
Thanks in advance,
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded Systems
> On Tue, 2 Oct 2007, Yasunori Goto wrote:
>
> > Do you mean that just nr_slabs should be checked like followings?
> > I'm not sure this is enough.
> >
> > :
> > if (s->node[nid]) {
> > n = get_node(s, nid);
> > if (!atomic_read(>nr_slabs)) {
> > s->node[nid] = NULL;
> >
Hello.
YOSHIFUJI Hideaki wrote:
> It is not a good practice. Please free such objects.
> BTW, how many objects do you have in the list?
It varies from 0 to some thousands,
depending on the policy supplied by the administrator and/or the policy
appended by "learning mode".
Peter Zijlstra
On Wed, 2007-10-03 at 23:19 +0900, Tetsuo Handa wrote:
> Hello.
>
> Thank you for pointing out.
>
> Peter Zijlstra wrote:
> > > Currently, TOMOYO Linux avoids read_lock, on the assumption that
> > > (1) First, ptr->next is initialized with NULL.
> > > (2) Later, ptr->next is assigned non-NULL
On Wed, 3 Oct 2007, Ilpo Järvinen wrote:
> On Wed, 3 Oct 2007, Frans Pop wrote:
>
> > The only change is in 2 consecutive columns: "2911 502" -> "2912 500".
> > Is processor usage calculated from those? Can someone explain how?
>
> The latter seems to be utime ...decreasing. No wonder if
On Wed, 3 Oct 2007, Frans Pop wrote:
> On Wednesday 03 October 2007, you wrote:
> > Try to capture the i/o log with the following command:
> > strace -o top.log top
>
> Thanks for the suggestion.
>
> > This will show for sure whether the kernel gives out incorrect data or
> > top misinterprets
On Wed, 3 Oct 2007, YOSHIFUJI Hideaki / µÈÆ£±ÑÌÀ wrote:
> In article <[EMAIL PROTECTED]> (at Wed, 3 Oct 2007 23:26:57 +0900), Tetsuo
> Handa <[EMAIL PROTECTED]> says:
>
> > Peter Zijlstra wrote:
> > > Also, how do you avoid referencing dead data with your sll? I haven't
> > > actually looked at
Since we now have all the tasks have non-zero pids we may
call the __pid_nr() instead of pid_nr() when the pid is
get from task with task_pid() or similar call.
Besides, there are some other places where the check for
pid to be not NULL is already done, so change them too.
Signed-off-by:
On Wed, 3 Oct 2007, Tetsuo Handa wrote:
> Regarding my singly-linked list, no entries are removed from the list.
> It's append only (like CD-R media). I set is_deleted flag of a entry
> instead of removing the entry from the list.
Why so?
This smells like a horrible leaking of memory. How
On Wed, 2007-10-03 at 23:19 +0900, Tetsuo Handa wrote:
> Hello.
>
> Thank you for pointing out.
>
> Peter Zijlstra wrote:
> > > Currently, TOMOYO Linux avoids read_lock, on the assumption that
> > > (1) First, ptr->next is initialized with NULL.
> > > (2) Later, ptr->next is assigned non-NULL
Hi, I use 2.6.22.9 with CFS-v22.
When I shutdown my laptop I see a error (last message on shutdown, after
"will be halt now"), but I can't read because is very fast (laptop
power-off automatically).
I see something about "Spindown error on ata-piix".
I try found on /var/log (messages, kern)
Some time ago Sukadev noticed that the vmlinux size has
grown 5Kb due to merged pid namespaces. One of the big
problems with it was fat inline functions. The other thing
was noticed by Matt - the checks for task's pid to be not
NULL take place and make the kernel grow due to inlining,
but these
On Wed, 2007-10-03 at 23:26 +0900, Tetsuo Handa wrote:
> Peter Zijlstra wrote:
> > Also, how do you avoid referencing dead data with your sll? I haven't
> > actually looked at your patches, but the simple scheme you outlined
> > didn't handle the iteration + concurrent removal scenario:
>
In article <[EMAIL PROTECTED]> (at Wed, 3 Oct 2007 23:26:57 +0900), Tetsuo
Handa <[EMAIL PROTECTED]> says:
> Peter Zijlstra wrote:
> > Also, how do you avoid referencing dead data with your sll? I haven't
> > actually looked at your patches, but the simple scheme you outlined
> > didn't handle
There are two places that do so - the cgroups subsystem
and the autofs code.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/fs/autofs/root.c b/fs/autofs/root.c
index 592f640..5efff3c 100644
--- a/fs/autofs/root.c
+++ b/fs/autofs/root.c
@@ -214,7 +214,7 @@ static struct
Peter Zijlstra wrote:
> Also, how do you avoid referencing dead data with your sll? I haven't
> actually looked at your patches, but the simple scheme you outlined
> didn't handle the iteration + concurrent removal scenario:
Regarding my singly-linked list, no entries are removed from the list.
On Wed, Oct 03, 2007 at 04:08:42PM +0200, Ingo Molnar wrote:
> > Charming... So we get d_path() either returning junk or we get
> > something that isn't NUL-terminated. Which one it is? I.e. what does
> > p look like and what's in s?
>
> could be use-after-free as well, as CONFIG_PAGEALLOC
Just make the __pid_nr() etc functions that expect the argument
to always be not NULL.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/include/linux/pid.h b/include/linux/pid.h
index e29a900..50b6899 100644
--- a/include/linux/pid.h
+++ b/include/linux/pid.h
@@ -135,21
On Wed, 3 Oct 2007 15:46:32 +0200 (MEST)
Mikael Pettersson <[EMAIL PROTECTED]> wrote:
> The proposed kernel signal delivery patch only handles the case
> where the /sigframe/ ends up overlapping the end of the altstack.
> If the sigframe remains within the altstack boundaries but the
> user-space
This is a pid which is attached to tasks when they detach
their pids. This is done in detach_pid() and transfer_pid().
The pid_alive() check is changed to reflect this fact.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/include/linux/sched.h b/include/linux/sched.h
index
On Mon, 1 Oct 2007, Linus Torvalds wrote:
> So there's a final -rc out there, and right now my plan is to make this
> series really short, and release 2.6.23 in a few days. So please do give
> it a last good testing, and holler about any issues you find!
The r8169 nic performance regression is
Hello.
Thank you for pointing out.
Peter Zijlstra wrote:
> > Currently, TOMOYO Linux avoids read_lock, on the assumption that
> > (1) First, ptr->next is initialized with NULL.
> > (2) Later, ptr->next is assigned non-NULL address.
> > (3) Assigning to ptr->next is done atomically.
> (4) wmb
On Wed, 2007-10-03 at 22:59 +0900, Tetsuo Handa wrote:
> Hello.
>
> KaiGai Kohei wrote:
> > If so, you can apply RCU instead to avoid read lock
> > when scanning the list, like:
> >
> > rcu_read_lock();
> > list_for_each_entry(...) {
> >
> > }
> > rcu_read_unlock();
>
> Can I sleep
* Al Viro <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 10:46:07AM +0200, Ingo Molnar wrote:
> >
> > hm, i just triggered the procfs crash below with -rc9 on a testbox.
> > Config attached. It's easy to reproduce it via 'service sshd restart'.
> > The crash site is:
> >
> > (gdb) list
On Wednesday 03 October 2007, you wrote:
> Try to capture the i/o log with the following command:
> strace -o top.log top
Thanks for the suggestion.
> This will show for sure whether the kernel gives out incorrect data or
> top misinterprets them.
PID USER PR NI VIRT RES SHR S %CPU
On Wed, 2007-10-03 at 15:35 +0200, Kay Sievers wrote:
> On Wed, 2007-10-03 at 12:37 +0200, Peter Zijlstra wrote:
> > On Wed, 2007-10-03 at 12:15 +0200, Kay Sievers wrote:
> > > On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
> > > > On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
>
Hello.
KaiGai Kohei wrote:
> If so, you can apply RCU instead to avoid read lock
> when scanning the list, like:
>
> rcu_read_lock();
> list_for_each_entry(...) {
>
> }
> rcu_read_unlock();
Can I sleep between rcu_read_lock() and rcu_read_unlock() ?
As far as I saw, rcu_read_lock()
** RFC not for inclusion **
Although this patch is against the -rt tree, it is also applicable to
mainline after Paul's RCU preempt patches make it in.
This patch adds RCU preemption boosting to RCU readers that were
preempted (or sleep due to spin_locks in -rt).
The approach I took is similar
Hello,
David Stevens wrote:
Dmitry,
Good catch; a couple comments:
Thank you for the response.
struct ipv6_pinfo *np = inet6_sk(sk);
int err;
+ int addr_type = ipv6_addr_type(addr);
+
+ if (addr_type == IPV6_ADDR_MAPPED) {
+ __be32 v4addr = addr->s6_addr32[3];
+
On Wed, 3 Oct 2007 22:20:46 +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 3 Oct 2007 21:40:29 +0900
> KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 3 Oct 2007 14:20:07 +0200 (MEST)
> > Mikael Pettersson <[EMAIL PROTECTED]> wrote:
> >
> > > What I don't agree with is the logic itself:
>
Gene Heskett wrote:
On Tuesday 02 October 2007, Bill Davidsen wrote:
Gene Heskett wrote:
Indeed it went to the system halted message and just sat there. I hadn't
yet booted to rc9 as amanda was running, so I did just a few minutes ago.
After the reboot to rc9, I ran a make xconfig
Tetsuo Handa wrote:
James Morris wrote:
I'm pretty sure that the singly linked list idea has been rejected a few
times. Just use the existing API.
Too bad...
Well, is there a way to avoid read_lock when reading list?
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1)
On Wed, 2007-10-03 at 12:37 +0200, Peter Zijlstra wrote:
> On Wed, 2007-10-03 at 12:15 +0200, Kay Sievers wrote:
> > On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
> > > On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
> > > > On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
> >
On Wed, Oct 03, 2007 at 10:46:07AM +0200, Ingo Molnar wrote:
>
> hm, i just triggered the procfs crash below with -rc9 on a testbox.
> Config attached. It's easy to reproduce it via 'service sshd restart'.
> The crash site is:
>
> (gdb) list *0xc017599d
> 0xc017599d is in seq_path
On Wed, 2007-10-03 at 22:04 +0900, Tetsuo Handa wrote:
> James Morris wrote:
> > I'm pretty sure that the singly linked list idea has been rejected a few
> > times. Just use the existing API.
> Too bad...
>
> Well, is there a way to avoid read_lock when reading list?
>
> Currently, TOMOYO
Correct the obvious "copy and paste" errors explaining some of the
"find_next" routines.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
arch/i386/lib/bitops.c|2 +-
arch/x86_64/lib/bitops.c |2 +-
include/asm-i386/bitops.h |5 ++---
3 files changed, 4 insertions(+),
On Wed, 3 Oct 2007 21:40:29 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> On Wed, 3 Oct 2007 14:20:07 +0200 (MEST)
> Mikael Pettersson <[EMAIL PROTECTED]> wrote:
>
> > What I don't agree with is the logic itself:
> > - You only catch altstack overflow caused by the kernel pushing
> > a
In article <[EMAIL PROTECTED]> (at Wed, 3 Oct 2007 22:04:11 +0900), Tetsuo
Handa <[EMAIL PROTECTED]> says:
> Well, is there a way to avoid read_lock when reading list?
>
> Currently, TOMOYO Linux avoids read_lock, on the assumption that
> (1) First, ptr->next is initialized with NULL.
> (2)
Frans Pop wrote:
I saw top occasionally displaying % CPU usage for a process. The
first few times it was amarokapp, this last time it was kontact.
Both applications were basically idle.
The "cc1" is a kernel compile (rc9 + CFS :-).
I cannot remember seeing this before, but as I also don't
James Morris wrote:
> I'm pretty sure that the singly linked list idea has been rejected a few
> times. Just use the existing API.
Too bad...
Well, is there a way to avoid read_lock when reading list?
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1) First, ptr->next is
On Wednesday 03 October 2007 22:17, Paul Jackson wrote:
> Nick wrote:
> > OK, so I don't exactly understand you either. To make it simple, can
> > you give a concrete example of a cpuset hierarchy that wouldn't
> > work?
>
> It's more a matter of knowing how my third party batch scheduler
> coders
On Wednesday 03 October 2007 22:41, Paul Jackson wrote:
> > pdflush
> > is not pinned at all and can be dynamically created and destroyed. Ditto
> > for kjournald, as well as many others.
>
> Whatever is not pinned is moved out of the top cpuset, on the kind of
> systems I'm most familiar with.
Am Mittwoch, 3. Oktober 2007 schrieb Joerg Platte:
Hi,
> 2.6.22.8:
> open("/dev/scanner", O_RDWR|O_NONBLOCK|O_EXCL) = 3
> ioctl(3, SG_SET_TIMEOUT, 0xbfe40624)= 0
> ioctl(3, SG_GET_VERSION_NUM, 0x8063fa4) = 0
> ioctl(3, SG_GET_SCSI_ID, 0xbfe405e0)= 0
>
> 2.6.23-rc9:
> open("/dev/scanner",
On (03/10/07 10:21), Ingo Molnar didst pronounce:
>
> * Mel Gorman <[EMAIL PROTECTED]> wrote:
>
> > > > Nice one Ingo - got it first try. The problem commit was
> > > > dd41f596cda0d7d6e4a8b139ffdfabcefdd46528 and it's clear that the
> > > > code removed in this commit is put back by this
On Oct 3 2007 14:33, Frans Pop wrote:
>
>I saw top occasionally displaying % CPU usage for a process. The
>first few times it was amarokapp, this last time it was kontact.
>Both applications were basically idle.
Yes this certainly sounds like KDE. Did you try with Gnome,
or perhaps a simple
On Tue, 2007-10-02 at 10:00 +0800, Fengguang Wu wrote:
> On Mon, Oct 01, 2007 at 11:57:34AM -0400, Chuck Ebbert wrote:
> > On 09/29/2007 07:04 AM, Fengguang Wu wrote:
...
>
> (expecting real world confirmations...)
>
> Here is a new safer version. It's more ugly though.
>
> ---
> writeback:
> pdflush
> is not pinned at all and can be dynamically created and destroyed. Ditto
> for kjournald, as well as many others.
Whatever is not pinned is moved out of the top cpuset, on the kind of
systems I'm most familiar with. They are put in a smaller cpuset, with
load balancing, that is sized
On Wed, 3 Oct 2007 14:20:07 +0200 (MEST)
Mikael Pettersson <[EMAIL PROTECTED]> wrote:
> What I don't agree with is the logic itself:
> - You only catch altstack overflow caused by the kernel pushing
> a sigframe. You don't catch overflow caused by the user-space
> signal handler pushing its
On Wed, 3 Oct 2007, YOSHIFUJI Hideaki / µÈÆ£±ÑÌÀ wrote:
> In article <[EMAIL PROTECTED]> (at Wed, 3 Oct 2007 20:24:52 +0900), Tetsuo
> Handa <[EMAIL PROTECTED]> says:
>
> > It seems that standard kernel list API does not have singly-linked list
> > manipulation.
> > I'm considering the
I saw top occasionally displaying % CPU usage for a process. The
first few times it was amarokapp, this last time it was kontact.
Both applications were basically idle.
The "cc1" is a kernel compile (rc9 + CFS :-).
I cannot remember seeing this before, but as I also don't run top that
On Wednesday 03 October 2007 22:14, Paul Jackson wrote:
> > These are what I'm worried about, and things like kswapd, pdflush,
> > could definitely use a huge amount of CPU.
> >
> > If you are interested in hard partitioning the system, you most
> > definitely want these things to be balanced
On Wed, 3 Oct 2007 09:58:44 +0200
Attila Kinali <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This patch adds the manufacturer and card id of teltonica
> pcmcia modems to serial_cs.c
>
> Signed-off-by: Attila Kinali <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
-
To unsubscribe from this
On Wed, 03 Oct 2007 17:06:24 +0900, Shi Weihua wrote:
> Fixing alternative signal stack wraparound.
>
> If a process uses alternative signal stack by using sigaltstack()
> and that stack overflow, stack wraparound occurs.
> This patch checks whether the signal frame is on the alternative
> stack.
On Wednesday 03 October 2007 12:45:42 am Casey Schaufler wrote:
> From: Casey Schaufler <[EMAIL PROTECTED]>
>
> Smack is the Simplified Mandatory Access Control Kernel.
>
> Smack implements mandatory access control (MAC) using labels
> attached to tasks and data containers, including files, SVIPC,
Nick wrote:
> OK, so I don't exactly understand you either. To make it simple, can
> you give a concrete example of a cpuset hierarchy that wouldn't
> work?
It's more a matter of knowing how my third party batch scheduler
coders think. They will be off in some corner of their code with a
cpuset
Hello,
I have done Streams multiplexers in Linux kernel. Created two multiplexers
and I could open these 2, close the file descriptors of each and could
link/unlink one with another properly .
But after linking, if i close the descriptor of the linked one: my signals
are unblocked
On Wed, Oct 03, 2007 at 01:56:46PM +0200, Ingo Molnar wrote:
>
> * Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Oct 03, 2007 at 12:55:34PM +0200, Dmitry Adamushko wrote:
> > ...
> > > just a quick patch, not tested and I've not evaluated all possible
> > > implications yet.
> > > But
> These are what I'm worried about, and things like kswapd, pdflush,
> could definitely use a huge amount of CPU.
>
> If you are interested in hard partitioning the system, you most
> definitely want these things to be balanced across the non-isolated
> CPUs.
But these guys are pinned anyway (or
On Sat, Sep 29, 2007 at 11:48:52AM +0200, Heiko Carstens wrote:
> > +static inline u64 compat_merge64(u32 left, u32 right)
> > +{
> > +#if defined(__BIG_ENDIAN)
> > + return ((u64)left << 32) | right;
> > +#else /* defined (__LITTLE_ENDIAN) */
>
> Could you change that to an #elif please and
On Tue, Oct 02, 2007 at 11:37:31PM +0200, Anders Bostr?m wrote:
> Hi!
>
> My computer suffers from high load average when the system is idle,
> introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
Another datapoint: I observe a similar effect on both of my alphas:
top - 09:30:43 up
* Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 12:55:34PM +0200, Dmitry Adamushko wrote:
> ...
> > just a quick patch, not tested and I've not evaluated all possible
> > implications yet.
> > But someone might give it a try with his/(her -- are even more
> > welcomed :-)
On Wednesday 03 October 2007 21:38, Paul Jackson wrote:
> > OK, so to really do anything different (from a non-partitioned setup),
> > you would need to set sched_load_balance=0 for the root cpuset?
> > Suppose you do that to hard partition the machine, what happens to
> > newly created tasks
On 9/28/07, Frans Pop <[EMAIL PROTECTED]> wrote:
> Current help for CONFIG_UEVENT_HELPER_PATH is:
>Path to uevent helper program forked by the kernel for
>every uevent.
> With default value of /sbin/hotplug.
>
> Help! I don't have /sbin/hotplug (Debian unstable, using udev).
> What do I do
From: Paul Jackson <[EMAIL PROTECTED]>
Thanks to Randy Dunlap for the review that caught
some of the following.
Some bug fixes and coding style fixes:
1) only one statement per line, please.
2) don't need to guard kfree() calls with a NULL check
3) use kfifo_free, not kfree, if it came from
In article <[EMAIL PROTECTED]> (at Wed, 3 Oct 2007 20:24:52 +0900), Tetsuo
Handa <[EMAIL PROTECTED]> says:
> It seems that standard kernel list API does not have singly-linked list
> manipulation.
> I'm considering the following list manipulation API.
Tstsuo, please name it "slist", which is
On Wed, Oct 03, 2007 at 12:55:34PM +0200, Dmitry Adamushko wrote:
...
> just a quick patch, not tested and I've not evaluated all possible
> implications yet.
> But someone might give it a try with his/(her -- are even more
> welcomed :-) favourite sched_yield() load.
Of course, after some
> OK, so to really do anything different (from a non-partitioned setup),
> you would need to set sched_load_balance=0 for the root cpuset?
Yup - exactly. In fact one code fragment in my patch highlights this:
/* Special case for the 99% of systems with one, full, sched domain */
On Tue, 2 Oct 2007, Jan Engelhardt wrote:
>
> On Oct 2 2007 23:49, Jimmy wrote:
>>
>> Anyway, I've been trying to figure out what purpose the gpl-only code serves.
>> What good comes out of disabling people from probing modules that do not
>> have a
>> gpl-compatible license?
>
> find
David Schwartz wrote:
* Jarek Poplawski <[EMAIL PROTECTED]> wrote:
BTW, it looks like risky to criticise sched_yield too much: some
people can misinterpret such discussions and stop using this at all,
even where it's right.
Really, i have never seen a _single_ mainstream app
Hello.
YOSHIFUJI Hideaki wrote:
> Introducing your own list is not good.
> Please use hlist or introduce new "slist".
James Morris wrote:
> You're introducing a custom API, which is open-coded repeatedly throughout
> your module.
>
> All linked lists (at least, new ones) must use the standard
On Tue, Oct 02, 2007 at 05:20:03PM -0500, Matt Mackall wrote:
> In lib/pagewalk.c, I've been using the various forms of
> {pgd,pud,pmd}_none_or_clear_bad while walking page tables as that
> seemed the canonical way to do things. Lately (eg with -rc7-mm1),
> these have been triggering messages like
Hi,
sane is not able to detect my old SCSI scanner with kernel 2.6.23-rc9. The
scanner was found with 2.6.22.8. According to strace the behavior of the
SG_GET_SCSI_ID ioctl changed:
2.6.22.8:
open("/dev/scanner", O_RDWR|O_NONBLOCK|O_EXCL) = 3
ioctl(3, SG_SET_TIMEOUT, 0xbfe40624)= 0
* Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
> + se->vruntime += delta_exec_weighted;
thanks Dmitry.
Btw., this is quite similar to the yield_granularity patch i did
originally, just less flexible. It turned out that apps want either zero
granularity or "infinite"
On Wed, Oct 03, 2007 at 12:58:26PM +0200, Dmitry Adamushko wrote:
> On 03/10/2007, Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
> > On 03/10/2007, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > > I can't see anything about clearing. I think, this was about charging,
> > > which should change the
Hello.
James Morris wrote:
> Would you please explain why you need another level of memory allocation?
>
> What does it do apart from let you check for memory leaks?
Difference between tmy_alloc() and kmalloc() are
tmy_alloc() allows administrator know "how much memory is used by TOMOYO
--- Fengguang Wu <[EMAIL PROTECTED]> wrote:
> Andrew,
>
> The following patches fix the sluggish writeback behavior.
> They are well understood and well tested - but not yet widely tested.
>
> The first patch reverts the debugging -mm only
> check_dirty_inode_list.patch -
> which is no longer
--- Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-10-01 at 14:22 -0700, Andrew Morton wrote:
>
> > nfs-remove-congestion_end.patch
> > lib-percpu_counter_add.patch
> > lib-percpu_counter_sub.patch
> > lib-percpu_counter-variable-batch.patch
> >
On Wed, 3 Oct 2007 03:45:09 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> > mm-use-pagevec-to-rotate-reclaimable-page.patch
> > mm-use-pagevec-to-rotate-reclaimable-page-fix.patch
> > mm-use-pagevec-to-rotate-reclaimable-page-fix-2.patch
> >
On Mon, Oct 01, 2007 at 01:10:59PM +0100, veerasena reddy wrote:
> Is there any problem if we use the below API's in
> linxu-2.6.18
> - dma_cache_wback_inv()
> - dma_cache_wback()
> - dma_cache_inv()
>
> functionality wise, especially in r4k.c i dont see any
> difference between the
On 03/10/2007, Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
> On 03/10/2007, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > I can't see anything about clearing. I think, this was about charging,
> > which should change the key enough, to move a task to, maybe, a better
> > place in a que (tree)
On 03/10/2007, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> I can't see anything about clearing. I think, this was about charging,
> which should change the key enough, to move a task to, maybe, a better
> place in a que (tree) than with current ways.
just a quick patch, not tested and I've not
On Wed, 3 Oct 2007 00:00:58 -0700 Paul Jackson <[EMAIL PROTECTED]> wrote:
> Nick wrote:
> > If code isn't ready to go, it doesn't need to rush, it can just be untangled
> > or fixed properly etc.
It's close enough for an rc1.
> True ... though we seem to be going in circles now. I doubt
>
* Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Hi,
>
> The below patch fixes a lockdep error in 2.6.23-rc9 when using
> tcp_probe.
>
> ---
>
> Subject: lockdep: annotate kprobes irq fiddling
>
> kprobes disables irqs for jprobes, but does not tell lockdep about it.
this resolves this
* Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
>
> Em Qua, 2007-10-03 às 09:08 +0200, Ingo Molnar escreveu:
> > FYI, there are 7 V4L drivers that produce this (non-fatal) warning:
>
> Those warnings are inoffensive ;) V4L core does provide a generic
> release callback. Anyway,
On Sat 2007-09-15 08:27:23, Anton Altaparmakov wrote:
> Hi,
>
> Mark Smith reported a OOM condition when he copies a
> large (46GiB) file from an NTFS partition (using the
> stock kernel driver) to /dev/ null (or to a file on
> ext3, same result).
>
> The machine this runs on has an i386
On Wednesday 03 October 2007 19:55, Paul Jackson wrote:
> > > Yeah -- cpusets are hierarchical. And some of the use cases for
> > > which cpusets are designed are hierarchical.
> >
> > But partitioning isn't.
>
> Yup. We've got a square peg and a round hole. An impedance mismatch.
> That's the
Hi,
The below patch fixes a lockdep error in 2.6.23-rc9 when using tcp_probe.
---
Subject: lockdep: annotate kprobes irq fiddling
kprobes disables irqs for jprobes, but does not tell lockdep about it.
CC: Prasanna S Panchamukhi <[EMAIL PROTECTED]>
CC: Ananth N Mavinakayanahalli <[EMAIL
On Wed, 2007-10-03 at 12:15 +0200, Kay Sievers wrote:
> On Tue, 2007-10-02 at 22:05 +1000, Nick Piggin wrote:
> > On Tuesday 02 October 2007 21:40, Peter Zijlstra wrote:
> > > On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
> >
> > > > How about adding this information to the tree then,
On Tuesday 02 October 2007 07:22, Andrew Morton wrote:
> remove-zero_page.patch
>
> Linus dislikes it. Probably drop it.
I don't know if Linus actually disliked the patch itself, or disliked
my (maybe confusingly worded) rationale?
To clarify: it is not zero_page that fundamentally causes a
201 - 300 of 716 matches
Mail list logo
