On 02/06/2015 06:49 AM, Raghavendra K T wrote:
Paravirt spinlock clears slowpath flag after doing unlock.
As explained by Linus currently it does:
prev = *lock;
add_smp(lock-tickets.head, TICKET_LOCK_INC);
/* add_smp() is a full mb() */
On 02/10/2015 05:26 AM, Oleg Nesterov wrote:
On 02/10, Raghavendra K T wrote:
On 02/10/2015 06:23 AM, Linus Torvalds wrote:
add_smp(lock-tickets.head, TICKET_LOCK_INC);
if (READ_ONCE(lock-tickets.tail) TICKET_SLOWPATH_FLAG) ..
into something like
val =
On 02/11/2015 09:24 AM, Oleg Nesterov wrote:
I agree, and I have to admit I am not sure I fully understand why
unlock uses the locked add. Except we need a barrier to avoid the race
with the enter_slowpath() users, of course. Perhaps this is the only
reason?
Right now it needs to be a locked
On 04/30/2015 03:53 AM, Juergen Gross wrote:
Paravirtualized spinlocks produce some overhead even if the kernel is
running on bare metal. The main reason are the more complex locking
and unlocking functions. Especially unlocking is no longer just one
instruction but so complex that it is no
On 05/03/2015 10:55 PM, Juergen Gross wrote:
I did a small measurement of the pure locking functions on bare metal
without and with my patches.
spin_lock() for the first time (lock and code not in cache) dropped from
about 600 to 500 cycles.
spin_unlock() for first time dropped from 145 to
On Tue, Apr 10, 2001 at 02:35:52PM +0200, Heusden, Folkert van wrote:
> So, I was wondering: isn't it a nice idea to have a switch in the
> configuration menu to disable entropy-gathering in the interrupt-routines,
> have some simplistic routine (like x'=(x * m + a) % p) which returns a non-
>
This is a fix for a potential deadlock in autofs4's expire routine.
It tries to use dput() while holding the dcache_lock. This isn't a
problem in principle since dput() should only try to take the dcache_lock
when the counter makes a transition to zero, which can't happen in
this case.
On Fri, Apr 20, 2001 at 05:00:04AM -0400, Alexander Viro wrote:
> Frankly, I'd rather add dput_locked() in dcache.c. The bug is real and
> since autofs4 is not the only place like that... I'll look into that
> stuff.
Sounds fine.
J
-
To unsubscribe from this list: send the line
On Fri, Apr 20, 2001 at 10:59:43PM -0700, Linus Torvalds wrote:
> It's untested, but looks fairly obvious. It removes the increment, and
> changes autofs4_expire() to properly bump the count of the returned dentry
> (and callers will dput() it when done). This may be unnecessarily careful,
> but
On Sat, Apr 21, 2001 at 02:21:38AM -0400, Alexander Viro wrote:
> Looks sane for me. However, I would add check for dentry being hashed and
> would skip the unhashed ones. Otherwise you can get a directory that
> had been removed but is still busy - doesn't look like a right thing to
> do.
On Fri, Apr 20, 2001 at 03:53:45PM -0400, Alexander Viro wrote:
> > Why are we doing the mntget/dget at all? We hold the spinlock, so we know
> > they are not going away. Not doing the mntget/dget means that we (a) run
> > faster and (b) don't have the bug, because we don't need to put the damn
>
Quoting John Martin <[EMAIL PROTECTED]>:
> this patch adds a check to make sure memory was allocated, returns an
> error code otherwise.
autofs4_dentry_ino doesn't allocate memory; it just extracts the fsdata pointer
from the dentry structure. If it's returning NULL, then there's something else
Quoting Russ Lewis <[EMAIL PROTECTED]>:
> mount -t userfs /etc/myfs.conf /myfs
I did this a while ago: I wrote userfs which allowed arbirary filesystems to be
implemented in user space. One of these was a filesystem which allowed you to
embed scripts in symlinks, such that stdout of the
On 15 Jun 2001 11:07:20 +0200, Helge Hafting wrote:
> The "resistance to scanning" seemed interesting, maybe one-time
> activities like a "find" run or big cat/dd will have less impact with
> this.
It should also be good for streaming file use. It gives a natural way
of detecting when you
On Thu, Oct 05, 2000 at 11:33:30AM +0200, Helge Hafting wrote:
> A power failure might leave you with a corrupt disk block. That is
> detectable (read failure) and you may then reconstruct it using the
> rest of the stripe. This will get you data from either before
> or after the update was
Hi,
I've been playing with user-mode linux (2.4.0-pre9). It works well on
one machine, but on my laptop I'm consistently getting stack overflows
just as init is started.
The backtrace (from a breakpoint at panic()):
(gdb) bt
#0 panic (fmt=0x10112e00 "Stack overflowed onto current_task page")
On Sun, Oct 08, 2000 at 12:35:48AM -0500, Jeff Dike wrote:
> I've been waiting for someone to send me that stack. There aren't any real
> smoking guns there. I'm guessing that the difference between your laptop and
> the machine it works on is that your laptop is running a fairly recent
On Sun, Oct 08, 2000 at 11:21:01AM -0500, Jeff Dike wrote:
> [EMAIL PROTECTED] said:
> > Even with this patch, the overflow is 808 bytes (without the patch
> > it's 1232 bytes).
>
> I was mulling over some other changes that would have saved another 256 bytes,
> but those don't look like they
On Sun, Oct 08, 2000 at 11:21:01AM -0500, Jeff Dike wrote:
> Also, could you look at the stack pointer at each frame, to see if you are
> encountering any stack hogs in the generic kernel? In a different situation,
> I found devfs putting a 3K structure on the stack.
OK, top candidates on
On Fri, Oct 20, 2000 at 03:16:14PM -0400, safemode wrote:
> That's what i was thinking, but 30MB/s seems to be quite an exaggeration.
I reliably get 30MB/s with my IBM 30G 7200rpm ATA66 drive, using a
Via VT82C586 controller. 2.4.0-test9. Modern drives are really fast.
J
-
To
S: Germany
N: Jeremy Fitzhardinge
-E: [EMAIL PROTECTED]
+E: [EMAIL PROTECTED]
+W: http://www.goop.org/~jeremy
+D: author of userfs filesystem
D: Improved mmap and munmap handling
D: General mm minor tidyups
-S: 67 Surrey St.
-S: Darlinghurst, Sydney
-S: New South Wales 2010
-S: Australia
+D:
On Fri, Oct 20, 2000 at 01:22:59PM -0700, Andre Hedrick wrote:
> On Fri, 20 Oct 2000 [EMAIL PROTECTED] wrote:
>
> > [EMAIL PROTECTED] wrote..
> >
> > > I reliably get 30MB/s with my IBM 30G 7200rpm ATA66 drive, using a
> > > Via VT82C586 controller. 2.4.0-test9. Modern drives are really fast.
On Wed, Oct 18, 2000 at 04:48:48PM +0100, Stephen Tweedie wrote:
> On Tue, Oct 17, 2000 at 12:31:24AM -0400, John Kacur wrote:
> > I'm trying to understand how the proc file system works. In particular
> > I'd like to know more about the algorithm by which the information is
> > updated and how
On Sat, Oct 21, 2000 at 01:37:26PM -0600, Jonathan Corbet wrote:
> physical address
> An address as known by the low-level hardware. In the modern
> world, these can be 64-bit quantities, even on 32-bit systems.
> These are the addresses used by /dev/mem - which appears to work
Hi,
/proc has no way to indicate whether tasks share an address space.
This one-liner patch adds a new ASID: field to /proc//status so
there's some way to see address-space sharing between tasks.
While this is hardly a bug-fix, it is a pretty useful thing to know
which is otherwise completely
On Thu, Oct 26, 2000 at 03:45:27PM -0700, I wrote:
> + buffer += sprintf("ASID: %p\n", mm);
Obviously, this should be:
+ buffer += sprintf("ASID:\t%p\n", mm);
for consistency.
J
PGP signature
On Thu, Oct 26, 2000 at 07:01:26PM -0400, Johannes Erdfelt wrote:
> and even more obvious:
>
> + buffer += sprintf(buffer, "ASID:\t%p\n", mm);
>
> Actually putting it into the buffer would be useful as well :)
That serves me right for hand-editing patches.
J
--
Repeat to self: I
On Tue, Oct 31, 2000 at 08:55:13PM +, Alan Cox wrote:
> Does autofs4 work yet
Autofs4 was fixed in 2.4.0-test10-pre6 or so. Autofs4 for 2.2.x has
been working for some time, though I just updated the 2.2 patch so it
doesn't stomp on autofs (v3).
J
PGP signature
I'm having problems with 1394 in 2.6.12-rc2-mm1. When I connect my
Apple iSight camera, it is not detected; repeated
connections/disconnections don't help. When I tried to rmmod all the
appropriate modules (rmmod video1394 raw1394 ohci1394 ieee1394), the
rmmod command hung. Alt-Sysreq-t shows
When running a Posix conformance test (from posixtestsuite), the kernel
locks up with:
BUG: soft lockup detected on CPU#0
Pid: 1873, comm: 10-1.test
EIP: 0060:[] CPU: 0
EIP is at sys_timer_settime+0xfa+0x1f0
EFLAGS: 0282 Not tainted (2.6.11-rc3-mm2)
EAX: 0282 EBX: 0001 ECX:
Jon Smirl wrote:
I didn't say make framebuffer depend on DRM, you can still unload DRM
before suspend. It's the other way around DRM needs framebuffer.
Only if you want to see the output, surely? I have an application which
doesn't need a framebuffer (or more strictly, scan-out), but does use
This patch implements compat_ioctl for joydev. I've tested it with a
Logitech WingMan Rumblepad on an x86-64 machine, and on an ia32
machine to make sure I didn't break anything.
Patch against stock 2.6.11, but also tested with 2.6.11-mm1.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTEC
Andrew Morton wrote:
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
+ if (!joydev->exist) return -ENODEV;
eww.
How's this? First patch is a (not particularly thorough)
indentation/whitespace cleanup, second implements compat_ioctl.
J
Index: local-2.6/drivers/input
if they
are), and therefore cannot be queued. There's therefore no risk of
resource starvation.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Index: local-2.6/kernel/signal.c
===
--- local-2.6.orig/kernel/signal.c 2005-02-22
Chris Wright wrote:
>It's not quite inexplicable. It means that task has hit its limit for
>pending signals ;-) But I agree, this should be fixed. I think I had
>tested this with broken test cases, thanks for catching.
>
>
It's particularly confusing for users, because it's a per-user limit
starvation.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Index: local-2.6/kernel/signal.c
===
--- local-2.6.orig/kernel/signal.c 2005-02-22 20:35:30.0 -0800
+++ local-2.6/kernel/signal.c 2005-02-23 14:57:23.0
Chris Wright wrote:
>>/proc/N/status will tell you that a process has
>>a signal pending, but it won't tell you how many are pending).
>>
>>
>
>Suggestion for good place to display that info?
>
>
I guess another line in /proc/N/status:
SigQue: 0 0 0 0 0 0 0 123 0 0 1238 0 0 0 0 0 ... 0
Roland McGrath wrote:
>Indeed, I think your patch does not go far enough. I can read POSIX to say
>that the siginfo_t data must be available when `kill' was used, as well.
>This patch makes it allocate the siginfo_t, even when that exceeds
>{RLIMIT_SIGPENDING}, for any non-RT signal (< SIGRTMIN)
Chris Wright wrote:
>It's an rlimit, so easily setable in userspace at login session time. I
>think we could raise it if people start complaining it's too low (hasn't
>seemed to be a problem yet).
>
Know any shells which support setting it? Indeed, glibc doesn't seem to
know about it.
J
-
On my IBM ThinkPad X31, I can only do one successful APM resume. After
the resume, there's a stream of messages on the console:
uhci_hcd :00:1d.0: host controller process error, something bad happened!
uhci_hcd :00:1d.0: host system error, PCI problems?
uhci_hcd :00:1d.0: host
Felix von Leitner wrote:
>>ACPI is the preferred (and only standardized) method of controlling cpu
>>throttling on x86 systems.
>>
>>
>
> 1. I don't trust ACPI
> 2. my battery runs out quicker with ACPI compared to cpufreq
>
>I _really_ _really_ don't want ACPI. No, really not. This is no
Though it looks a lot better; no more streams of messages.
Now when I resume, I get:
PCI: Enabling device :00:1d.7 ( -> 0002)
<1>Unable to handle kernel NULL pointer dereference
a second or so after resume. It is completely locked up at this point;
magic-sysreq gets no response.
lspci
I was just looking at agp_copy_info(), which contains this code:
318 if (bridge->mode & AGPSTAT_MODE_3_0)
319 info->mode = bridge->mode & ~AGP3_RESERVED_MASK;
320 else
321 info->mode = bridge->mode & ~AGP2_RESERVED_MASK;
322 info->mode = bridge->mode;
This
Andrew Morton wrote:
> On Sun, 17 Dec 2006 20:55:18 -0500
> "Andrew J. Barr" <[EMAIL PROTECTED]> wrote:
>
>
>> When I was using gdb to debug xchat-gnome, I got a kernel BUG and stack
>> trace as the program was running (e.g. I had typed 'run' in gdb):
>>
>> WARNING at kernel/softirq.c:137
Frederik Deweerdt wrote:
> Same problems here with 2.6.20-rc1-mm1 (ie with the %gs->%fs patch).
> It seems to me that the problem comes from the EFL_OFFSET no longer
> beeing accurate.
> The following patch fixes the problem for me.
>
Thanks Frederik; that's exactly the kind of thing I thought
Frederik Deweerdt wrote:
> It works too, thanks. BTW, I wondered if the "case GS:" in getreg() made
> sense now?
Sorry, what do you mean? It looks OK to me, but I'm not sure what
you're referring to.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Ingo Molnar wrote:
> Subject: [patch] change WARN_ON back to "BUG: at ..."
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> WARN_ON() ever triggering is a kernel bug. Do not try to paper over this
> fact by suggesting to the user that this is 'only' a warning, as the
> following recent commit does:
>
Frederik Deweerdt wrote:
> Following the i386 pda patches, it's not possible to set gs or fs value
> from gdb anymore. The following patch restores the old behaviour of
> getting and setting thread.gs of thread.fs respectively.
> Here's a gdb session *before* the patch:
> (gdb) info reg
> [...]
>
Frederik Deweerdt wrote:
> This is a -mm1 kernel + your efl_offset fix + the attached patch.
> So the problem came from putreg still saving %gs to the stack where
> there's no slot for it, whereas getreg got things right.
>
That patch looks good, but I think it is already effectively in
Andrew Morton wrote:
> The below is what I have queued for urgent mainlining to address these
> problems.
>
> Is it sufficient?
>
It is sufficient to fix the serious eflags-clobbering bug, but it
doesn't fix the read-and-modify correctness problem Frederik found.
J
-
To unsubscribe from
Frederik Deweerdt wrote:
> On Thu, Dec 21, 2006 at 11:22:05AM -0800, Jeremy Fitzhardinge wrote:
>
>> Frederik Deweerdt wrote:
>>
>>> Following the i386 pda patches, it's not possible to set gs or fs value
>>> from gdb anymore. The following patch resto
Andrew Morton wrote:
> OK, but you're using -mm, yes? And -mm has (the rather irritating)
> convert-i386-pda-code-to-use-%fs.patch in it.
>
> So perhaps your fix is a -mm-only thing?
>
Yes, I think that's true.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Rene Herman wrote:
> Jeremy? Is it okay to only check the signature word? The checksum will
> generally be done over more than 1 (hw) page... That "presumably"
> there seems a bit flaky?
Well, in the Xen case, where the pages are simply not mapped, then the
signature simply won't exist. In
Rene Herman wrote:
> In your opinion, is the attached (versus 2.6.20-rc3) better? This uses
> probe_kernel_address() for all accesses. Or rather, an expanded
> version thereof. The set_fs() and pagefault_{disable,enable} calls are
> only done once in probe_roms().
>
> Accessing the length byte at
Rene Herman wrote:
> How is it for efficiency? I thought it was for correctness.
> romsignature is using probe_kernel_adress() while all other accesses
> to the ROMs there aren't.
>
> If nothing else, anyone reading that code is likely to ask himself the
> very same question -- why the one, and
Rene Herman wrote:
> Doing the set_fs() and pagefault_{disable,enable} calls for every
> single byte during the checksum seems rather silly.
Why? It's a bit of a performance hit, but that doesn't matter here.
probe_kernel_address() is semantically the right thing to be using;
open-coding its
I'm wondering if activate_mm() is the right thing to be using in
use_mm(); shouldn't this be switch_mm()?
On normal x86, they're synonymous, but for the Xen patches I'm adding a
hook which assumes that activate_mm is only used the first time a new mm
is used after creation (I have another hook
Jeremy Fitzhardinge wrote:
> I'm wondering if activate_mm() is the right thing to be using in
> use_mm(); shouldn't this be switch_mm()?
>
> On normal x86, they're synonymous, but for the Xen patches I'm adding a
> hook which assumes that activate_mm is only used the first time a n
It would be terribly useful to have some way of
lseeking /proc//maps to the entry of a particular address. So, if
you want to find the information about a mapping containing address
0x12345678, it would set the file position to (say) the entry of
0x1200-0x2000.
I haven't looked at how
Christoph Lameter wrote:
> On Wed, 6 Dec 2006, Mel Gorman wrote:
>
>> Objective: Get contiguous block of free pages
>> Required: Pages that can move
>> Move means: Migrating them or reclaiming
>> How we do it for high-order allocations: Take a page from the LRU, move
>> the pages within
Christoph Lameter wrote:
> The same can be done using the virtual->physical mappings that exist on
> many platforms for the kernel address space (ia64 dynamically calculates
> those, x86_64 uses a page table with 2M pages for mapping the kernel).
Yes, that's basically what Xen does - there's a
Arkadiusz Miskiewicz wrote:
> LD .tmp_vmlinux1
> arch/i386/kernel/built-in.o: In function `math_emulate':
> (.text+0x3809): undefined reference to `_proxy_pda'
>
Hm, in theory nothing should ever generate a reference to _proxy_pda.
What compiler are you using?
J
-
To unsubscribe
Andi Kleen wrote:
>> binutils-2.17.50.0.8-1.i686
>> gcc-4.2.0-0.20061206r119598.2.i686
>>
>
> Hmm, that's not even a release -- afaik gcc 4.2 isn't out yet.
>
> Can you please do
>
> make arch/i386/math-emu/fpu_entry.i
> make arch/i386/math-emu/fpu_entry.s
>
> and send me the resulting .i and
Meelis Roos wrote:
> This if from todays git (2006-12-08):
>
> CC arch/ppc/kernel/asm-offsets.s
> In file included from arch/ppc/include/asm/bug.h:97,
> from include/linux/kernel.h:18,
> from include/asm/system.h:7,
> from
Andi Kleen wrote:
> Looking at Arkadiusz' output file it looks like gcc 4.2 decided to CSE the
> address :/
>
> movl$_proxy_pda+8, %edx #, tmp65
>
> Very sad, but legitimate.
>
Yes, that was my conclusion too. Though in this case the code could be
cleaned up by cutting down on
Andi Kleen wrote:
> The trouble is when it's CSEd it actually causes worse code because
> a register is tied up. That might not be worth the advantage of having it?
>
I think so, definitely; without proxy_pda you need to make it asm
volatile+mem clobber, which completely eliminates all
Paul Cameron Davies wrote:
> The PTI gathers all the open coded iterators togethers into one place,
> which would be a good precursor to providing generic iterators for
> non performance critical iterations.
>
> We are completing the updating/enhancements to this PTI for the latest
> kernel, to be
Meelis Roos wrote:
>> Hm, what's your .config?
>>
>
> Below. It's a PReP machine so using the old ppc arch.
>
>
>> Hey, what's arch/pps/include/asm/bug.h? Is your tree clean?
>>
>
> Tree is clean
So why don't I have arch/ppc/include/asm/bug.h in my tree here?
It does look like the
Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Since Voyager and Visual WS already define ARCH_SETUP,
> it looks like PARAVIRT shouldn't be offered for them.
>
> In file included from arch/i386/kernel/setup.c:63:
> include/asm-i386/mach-visws/setup_arch.h:8:1: warning:
xu feng wrote:
> I am just confused about the author:
> 1- first point, why the cache has to be bothered by
> the change in the address logical-physical mapping
> since it is a virtual cache??
>
If you:
1. mmap file A at virtual address X
2. use memory at X
3. mmap file B at X
4.
Hi Andi,
What problem do they cause together? There's certainly no problem with
Xen+vdso (in fact, its actually very useful so that it picks up the
right libc with Xen-friendly TLS).
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Zachary Amsden wrote:
> Jeremy Fitzhardinge wrote:
>> Hi Andi,
>>
>> What problem do they cause together? There's certainly no problem with
>> Xen+vdso (in fact, its actually very useful so that it picks up the
>> right libc with Xen-friendly TLS).
>>
&
Zachary Amsden wrote:
> It's not for us or Xen. Perhaps it came from lhype?
(I suspect it came from Andi's fevered brain.) If lhype can't deal with
vdso, it can turn it off for itself - but I don't think its a problem
for lhype.
J
-
To unsubscribe from this list: send the line
Chuck Ebbert wrote:
> This whole thing needs a proper fix IMO. I posted something a while back
> but Andi didn't like it, I guess.
>
What's a quick summary of the issue again?
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Theodore Tso wrote:
> P.S. For people who live in the US; write your congresscritters; the
> MPAA wants to propose new legislation stating exactly this.
>
(Erm, that was a joke on a parody site; it got widely reported as "news".
http://www.bbspot.com/News/2006/11/home-theater-regulations.html
Ingo Molnar wrote:
> what point would there be in using it? It's not like the kernel could
> make use of the thread keyword anytime soon (it would need /all/
> architectures to support it) ...
The plan was to implement the x86 arch-specific percpu stuff to use it,
since it allows gcc better
Stephane Eranian wrote:
> Here is a small patch that adds two cpufeature bits to represent
> Intel's Precise-Event-Based Sampling (PEBS) and Branch Trace Store
> (BTS) features. Those features can be found on Intel P4 and Core 2
> processors among others and can be used by perfmon.
>
I've
Andi Kleen wrote:
> I have had private patches for that myself, using the MSRs on AMD
> and Intel.
>
Would they be something that could be cleaned up into something
mergeable? It would be nice to have something that could be left
enabled all the time, but an option would at least make the
processors are noticably slower
when %fs is used rather than %gs; I have no idea why this might be,
but I think they're sufficiently rare that it doesn't matter much.
This patch also fixes the math emulator, which had not been adjusted
to match the changed struct pt_regs.
Signed-off-by: Jeremy Fi
ed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Eric Dumazet <[EMAIL PROTECTED]>
diff -r 022c29ea754e arch/i386/kernel/cpu/common.c
--- a/arch/i386/kernel/cpu/common.c Tue Nov 21 18:54:56 2006 -0
Eric Dumazet wrote:
> if !CONFIG_SMP, why even dereferencing boot_pda+PDA_cpu to get 0 ?
> and as PER_CPU(cpu_gdt_descr, %ebx) in !CONFIG_SMP doesnt need the a value in
> ebx, you can just do :
>
> #define CUR_CPU(reg) /* nothing */
>
Yep. On the other hand, I think that's an incredibly rare
Andi Kleen wrote:
> Hmm, it probably needs a EXPORT_SYMBOL. The previous change only
> fixed the in kernel build.
>
> Does it work with this patch?
>
> -Andi
>
> Export _proxy_pda for gcc 4.2
>
Gak. It seemed like such a good idea at the time.
Rusty's pda->per_cpu patch will deal with this
Andi Kleen wrote:
>> Rusty's pda->per_cpu patch will deal with this once and for all; have
>>
>
> Not on x86-64.
>
Have you considered dropping pda in x86-64? Segment based percpu
doesn't really have any disadvantages.
>> you picked it up yet?
>>
>
> Not yet.
>
There will be
Subject: Simplify smp_call_function*() by using common implementation
smp_call_function and smp_call_function_single are almost complete
duplicates of the same logic. This patch combines them by
implementing them in terms of the more general
smp_call_function_mask().
Signed-off-by: Jeremy
Paul Mackerras wrote:
> There is a fundamental problem with using __thread, which is that gcc
> assumes that the addresses of __thread variables are constant within
> one thread, and that therefore it can cache the result of address
> calculations. However, with preempt, threads in the kernel
Rusty Russell wrote:
> + pack_descriptor((u32 *)[GDT_ENTRY_PERCPU].a,
> + (u32 *)[GDT_ENTRY_PERCPU].b,
> + __per_cpu_offset[cpu], 0xF,
> 0x80 | DESCTYPE_S | 0x2, 0); /* present read-write data
> segment */
>
Why testing
Nick Piggin wrote:
> However we still have to visit those to-be-unmapped parts of the page
> table,
> to find the pages and free them. So we still at least need to bring it
> into
> cache for the read... at which point, the store probably isn't a big
> burden.
Why not try to find a place to stash
Andi Kleen wrote:
> On Tue, Mar 13, 2007 at 05:39:36PM +1100, Rusty Russell wrote:
>
>> GCC (4.1 at least) unrolls it anyway, but I can't believe this code
>>
>
> Are you sure? Normally it doesn't unroll without -funroll-loops which
> the kernel does normally not set. Especially not with
Andrew Morton wrote:
> Correctly matching the section annotation on declarations and definitions
> is needed by at least ARM. We should ensure that we do this on all future
> patches and we should also apply this patch if only for this reason.
>
> (The ARM thing is a pain, because the compiler
David Schwartz wrote:
> Good interactivity for tasks that aren't themselves CPU hogs. A task should
> get low latency if and only if it's yielding the CPU voluntarily most of the
> time. If it's not, it can only get better interactivity at the cost of
> fairness, and you have to *ask* for that.
David Schwartz wrote:
>> There's a distinction between giving it more cpu and giving it higher
>> priority: the important part about having high priority is getting low
>> latency access to the cpu when its needed.
>>
>
> I agree. Tasks that voluntarily relinquish their timeslices should get
Matt Mackall wrote:
> On Tue, Mar 13, 2007 at 10:30:10AM -0700, Jeremy Fitzhardinge wrote:
>
>> Nick Piggin wrote:
>>
>>> However we still have to visit those to-be-unmapped parts of the page
>>> table,
>>> to find the pages and
Rusty Russell wrote:
> Hi all,
>
> The GDT stuff on x86 is a little more complex than it need be, but
> playing with boot code is always dangerous. These compile and boot on
> UP and SMP for me, but Andrew should let the cook in -mm for a while.
>
Hi Rusty,
This is my rough hacking
Andi Kleen wrote:
> On Thu, Mar 01, 2007 at 06:54:24PM -0800, Zachary Amsden wrote:
>
>> The custom_sched_clock hook is broken. The result from sched_clock needs to
>> be
>> in nanoseconds, not in CPU cycles. The TSC is insufficient for this purpose,
>> because TSC is poorly defined in a
The current Linux scheduler makes one big assumption: that 1ms of CPU
time is the same as any other 1ms of CPU time, and that therefore a
process makes the same amount of progress regardless of which particular
ms of time it gets.
This assumption is wrong now, and will become more wrong as
john stultz wrote:
> My gut reaction would be to avoid using clocksources for now. While
> there is some thought going into how to expand clocksources for other
> uses (Daniel is working on this, for example), the design for
> clocksources has been very focused on its utility to timekeeping, so
Matt Mackall wrote:
> Well you -could- do this:
>
> - reuse a long in struct page as a used map that divides the page up
> into 32 or 64 segments
> - every time you set a PTE, set the corresponding bit in the mask
> - when we zap, only visit the regions set in the mask
>
> Thus, you avoid
Rusty Russell wrote:
> This is called "pissing in the corners". Don't do it: we don't need to
> touch that code and I actually prefer the original anyway (explicit is
> *good*).
>
> The habit of extracting cpu number once then using it is an optimization
> which we should be aiming to get rid
Andi Kleen wrote:
> It depends -- under heavy network load you can spend a long time
> just processing interrupts.
Well, in that case you probably don't want to charge them to the process
which happens to be running at the time.
J
-
To unsubscribe from this list: send the line "unsubscribe
Daniel Walker wrote:
> The frequency tracking you mention is done to some extent inside the
> timekeeping adjustment functions, but I'm not sure it's totally accurate
> for non-timekeeping, and it also tracks things like interrupt latency.
> Tracking frequency changes where it's important to get
1 - 100 of 3704 matches
Mail list logo
