hanged.
Surely I've misunderstood something in the timer code ?
Can anyone shed some light on this ?
Thanks for your help,
-jamie.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
n we
> go to tear down.
>
> A coworker at lunch actually pointed out to me that the reason this is
> true is just that modular arithmatic is still associative with addition
> and subtraction.
It's just like jiffies. Everyone understands jiffies arithmetic I hope.
-- Jamie
--
T
gt; +int pthread_rwlock_init(pthread_rwlock_t *rwlock,
> + const pthread_rwlockattr_t *attr)
> +{
> + if (ll_pthread_rwlock_init == NULL)
> + init_preload();
Why is this one special, doesn't init_preload being a constructor make
this redundant?
Jamie
--
To unsubscribe fro
On Thu, Feb 07, 2013 at 09:31:22AM -0500, Sasha Levin wrote:
> On 02/07/2013 05:28 AM, Jamie Iles wrote:
> >> +int pthread_rwlock_init(pthread_rwlock_t *rwlock,
> >> > +const pthread_rwlockattr_t *attr)
> >> > +{
> >>
On Thu, Mar 28, 2013 at 09:46:45PM +0100, Maxime Ripard wrote:
> Now that the arm core code calls irqchip_init, we can remove it from all
> the machines that were using it.
>
> Signed-off-by: Maxime Ripard
> Acked-by: Simon Horman
Acked-by: Jamie Iles
Thanks Maxime!
--
To u
Seems like a better alternative to microcode_ctl which some distros don't
contain.
Regards,
Jamie Gloudon
On Mon, Oct 01, 2012 at 06:27:45PM +0200, Borislav Petkov wrote:
> On Mon, Oct 01, 2012 at 12:11:51PM -0400, Jamie Gloudon wrote:
> > Hey,
> >
> > Any chance
On Tue, Oct 02, 2012 at 06:39:54AM +0200, Borislav Petkov wrote:
> On Mon, Oct 01, 2012 at 07:37:04PM -0400, Jamie Gloudon wrote:
> > On Mon, Oct 01, 2012 at 06:27:45PM +0200, Borislav Petkov wrote:
> > > On Mon, Oct 01, 2012 at 12:11:51PM -0400, Jamie Gloudon
Hi Axel,
On Sun, Nov 04, 2012 at 11:36:25PM +0800, Axel Lin wrote:
> The platform_device_id table is supposed to be zero-terminated.
>
> Signed-off-by: Axel Lin
Good spot! Thanks for fixing.
Acked-by: Jamie Iles
Jamie
--
To unsubscribe from this list: send the line "uns
Building with a large config and -ffunction-sections results in a large
number of sections and sortextable needs to be able to handle that.
Implement support for > 64K sections as modpost does.
Cc: David Daney
Cc: H. Peter Anvin
Signed-off-by: Jamie Iles
---
scripts/sortextable.c |
rresponding check
instructions (ld.c / chk.a). The default is 'enable'.
I don't know if that results in value speculation of the relevant kind.
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.k
: Jamie Liu
---
include/linux/stop_machine.h | 13 +
kernel/stop_machine.c| 16
kernel/workqueue.c | 4 +++-
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/include/linux/stop_machine.h b/include/linux/stop_machine.h
index 3b5e910..a315f92
hine while preventing anything else from
> happening on all other CPUs. The two would deadlock.
>
> Jmamie Liu reports that this deadlock scenario exists around
s/Jmamie/Jamie/
> scsi_requeue_run_queue() and libata port multiplier support, where one
> port may exclude command pro
Hi Andreas,
Just calling cond_resched() does appear to be the more general
solution, and is already on tj/wq/for-next as
b22ce2785d97423846206cceec4efee0c4afd980 "workqueue: cond_resched()
after processing each work item".
Thanks,
Jamie
On Thu, Aug 29, 2013 at 1:45 PM, Andreas M
> + uart.port.flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_FIXED_PORT;
> uart.port.dev = &pdev->dev;
>
> + uart.port.membase = ioremap(regs->start, regs->end - regs->start);
Doesn't this have an off-by-one error? Perhaps:
+ uart.port.membase = ioremap(r
able to
> deliver their UART's capabilities when they are registering ports.
Other than my comment on 3/5 it looks great.
Reviewed-by: Jamie Iles
Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vge
Looks good to me!
On Tue, Dec 04, 2012 at 05:21:52PM +0200, Heikki Krogerus wrote:
> This needs to be done in order to later access the
> Designware specific registers.
>
> Signed-off-by: Heikki Krogerus
Reviewed-by: Jamie Iles
--
To unsubscribe from this list: send the line
On Mon, Nov 05, 2012 at 09:06:44AM +, Jamie Iles wrote:
> Building with a large config and -ffunction-sections results in a large
> number of sections and sortextable needs to be able to handle that.
> Implement support for > 64K sections as modpost does.
>
> Cc: David Dan
t; exception return to get back to the new code -- depends on how your
> stop/resume code works).
If I've understood that exchange, it implies that using patch_text()
to replace an instruction not in the list of special ones, with a trap
or jump, isn't ok? And so it's ok to repla
-xorg-video-nouveau 1:1.0.1-3
and mplayer2 2.0-600-g95e81df w/the xv video output driver
> git bisect identified the following culprit:
>
> 11d92561c81be2f4a7af37f035e1af294b960abe is the first bad commit
I bisected to the same commit as well.
--
Jamie Heilman http:
the core timer and the dt addon.
>
> As dw_apb_timer_of always depends on dw_apb_timer let it select
> DW_APB_TIMER itself without the need for every platform to do it.
>
> Signed-off-by: Heiko Stuebner
Acked-by: Jamie Iles
--
To unsubscribe from this list: send the line "un
> The clock-frequency property is kept to act as fallback if no clocks
> are specified.
>
> Signed-off-by: Heiko Stuebner
Acked-by: Jamie Iles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
source as sched_clock instead.
>
> Therefore enable the driver to distiguish between devices with and without
> sptimer based on the devicetree data and select the correct timer as
> sched_clock.
>
> Signed-off-by: Heiko Stuebner
Acked-by: Jamie Iles
--
To unsubscribe from this list:
"picochip,pc3x2-timer",
> dw_apb_timer_init);
> +CLOCKSOURCE_OF_DECLARE(apb_timer, "snps,dw-apb-timer-osc",
> dw_apb_timer_init);
I think maybe we also want CLOCKSOURCE_OF_DECLARE() instances for the
contents of sptimer_ids for completeness, otherwise looks good.
Ac
Hi Ben, Willy,
On Fri, Jun 07, 2013 at 06:42:05AM +0100, Ben Hutchings wrote:
> On Tue, 2013-06-04 at 19:23 +0200, Willy Tarreau wrote:
> > 2.6.32-longterm review patch. If anyone has any objections, please let me
> > know.
> >
> > --
> > d
s inclomplete serial support.
>
> Then we just make minor patches to 8250_dw, and rip out all this
> OCTEON code.
>
> Since the patches are all interdependent, we might want to merge them
> via a single tree (perhaps Ralf's MIPS tree).
Looks good!
Reviewed-by: Jamie Iles
for
Building with a large config and -ffunction-sections results in a large
number of sections and sortextable needs to be able to handle that.
Implement support for > 64K sections as modpost does.
Cc: Rusty Russell
Signed-off-by: Jamie Iles
---
scripts/sortextable.c |
Hi Maxime,
Thanks for this, I'll add it to my tree. I've modified it slightly to
kill off the other irq includes, hopefully that's okay with you.
Thanks,
Jamie
8<---
>From 4b83f75a7af388aaf5f79ccf72c37074bc9166da Mon Sep 17 00:00:00 2001
From: Maxime Ripard
Date: Tue,
t exists on both
> platforms, and adds missing of_node_put() in dw_apb_timer_init().
>
> Signed-off-by: Pavel Machek
Acked-by: Jamie Iles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
rk as osctimer_ids is private to the dw_apb_timer files
as is timer_get_base_and_rate. The other timer is unused in picoxcell
though so dw_apb_timer_init(1), something like the patch below on top of
yours.
Thanks,
Jamie
diff --git i/arch/arm/mach-picoxcell/common.c w/arch/arm/mach-picoxce
Hi Thomas,
On Thu, Apr 25, 2013 at 08:31:43PM -, Thomas Gleixner wrote:
> Signed-off-by: Thomas Gleixner
> Cc: Jamie Iles
Looks good, thanks for fixing this.
Acked-by: Jamie Iles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
On Thu, May 16, 2013 at 10:19:56AM +0200, Maxime Ripard wrote:
> Hi Jamie,
>
> Le 14/05/2013 18:20, Jamie Iles a écrit :
> > Hi Maxime,
> >
> > Thanks for this, I'll add it to my tree. I've modified it slightly to
> > kill off the other irq includes,
ultz
> Cc: Thomas Gleixner
> Cc: Jamie Iles
Acked-by: Jamie Iles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
49bfe90136653c. (I say
based on, because I have to apply the patch from
http://marc.info/?l=linux-nfs&m=133950479803025 or face additional
problems.)
I'll try to get full rcpdebug traces on client and server as the delay
is occuring in the hopes that helps pin things down, and post them
sep
Jamie Heilman wrote:
> I'll try to get full rcpdebug traces on client and server as the delay
> is occuring in the hopes that helps pin things down, and post them
> separately.
OK, here are the logs from client and server, where a run of my test program
under strace -T resulted in:
J. Bruce Fields wrote:
> On Wed, Aug 15, 2012 at 01:58:54PM +0000, Jamie Heilman wrote:
> > Jamie Heilman wrote:
> > > I'll try to get full rcpdebug traces on client and server as the delay
> > > is occuring in the hopes that helps pin things down, and post them
>
one that was updated, but the
> former was the one that the callback used.
>
> Symptoms were a long delay on utime(). This is because the utime()
> generated a setattr which recalled a delegation, but the cb_recall was
> ignored by the client because it had the wr
Commit: 96ff0f5c7efd4a2205c48a76a6a1fcd2731e6128
> Parent: f4a00139b7cbeff538e616a21f6b57249a9d3ed8
> Author: Jamie Lentin
> AuthorDate: Sat Nov 17 09:51:04 2012 +0100
> Committer: Jason Cooper
> CommitDate: Sat Nov 24 02:56:38 2012 +
>
> power: Add simple poweroff-gpio drive
your output looks like with the full amount on 3.6?
Jamie Gloudon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
I was also skeptical about DirectMap results added up being less than
MemTotal. I see now, Thanks for the explanation.
Jamie Gloudon
On Mon, Oct 01, 2012 at 08:23:38AM -0700, Hugh Dickins wrote:
> On Mon, 1 Oct 2012, Jamie Gloudon wrote:
> >
> > Interesting. I am able to rep
Hey,
Any chance of this getting merge for the 3.7 cycle?
Regards,
Jamie Gloudon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pleas
here should be
enough space for the size change node, provided GC is invoked when
necessary and the node sizes are compatible for this in corner cases.
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majord
For a while, I've been meaning to bring it up on linux-kernel...
The fsync problem
-
Chris Wedgwood wrote:
> On Mon, Feb 25, 2008 at 08:50:40PM +, Jamie Lokier wrote:
>
> > On Linux (and other host OSes), fdatsync() and fsync() don't always
> > commit
Jeff Garzik wrote:
> Jamie Lokier wrote:
> >By durable, I mean that fsync() should actually commit writes to
> >physical stable storage,
>
> Yes, it should.
Glad we agree :-)
> >I was surprised that fsync() doesn't do this already. There was a lot
> >of ef
Andrew Morton wrote:
> On Tue, 26 Feb 2008 07:26:50 +0000 Jamie Lokier <[EMAIL PROTECTED]> wrote:
>
> > (It would be nicer if sync_file_range()
> > took a vector of ranges for better elevator scheduling, but let's
> > ignore that :-)
>
> Two passes:
>
no_ new APIs.
It offers ordering barriers only, which aren't enough. I tried to
explain, discuss some changes and then suggest optimisations.
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
equivalent to AIO-style
fdatasync() on a limited range of offsets, and WAIT_AFTER seems to be
equivalent to waiting for any previously issued such ops to complete.
Any data access metadata updates that btrfs must make for fdatasync(),
it must also make for sync_file_range(), for the limited range of
o
lush not just the disks with data pages, but the _other_
disks in a software RAID with data pointer metadata pages, but ideally
not all of them (think database journal commit).
That can be implemented with per-buffer pending-barrier/flush flags
(like I described for pages in the first mail), which
fdatasync() work well, with a genuine flush (or
equivalent (see FUA), only when required, and not a mere ordered
barrier), no inode write, and to make sync_file_range()[*] offer the
fancier applications finer controls which reflect what they actually
need.
[*] - or whatever.
-- Jamie
--
To un
ce in most cases.
Apps: don't always want a full flush; sometimes a barrier would do.
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jörn Engel wrote:
> On Tue, 26 February 2008 15:28:10 +0000, Jamie Lokier wrote:
> >
> > > One interesting aspect of this comes with COW filesystems like btrfs or
> > > logfs. Writing out data pages is not sufficient, because those will get
> > > lost unless t
This is kernel 2.4.2, as kernel 2.4.3 doesn't seem to work with pppd's
chat program.
Spot the incongruity below! (It will go to -4 when I disconnect).
This is on a laptop, which is suspended from time to time. Maybe this
gives a clue as to what's causing the fault.
enjoy,
-
ven on Intel MTRRs are not enabled for 2.5M
framebuffers.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
r program then tries to access data
referenced by that segment register, user space will get a
general_protection fault. As it's only user space that calls modify_ldt
to invalidate an LDT entry, that's reasonable.
There's one thing that confuses me: don't you get a segment_not_present
fault? I
l.. I peeked into traps.c.. I do seem a call to die_if_no_fixup
> in this function. And I think loadsegment is already making an entry in
> exception table.
Ah, you're right. I didn't follow DO_ERROR all the way to do_trap and
hency search_exception_table.
-- Jamie
-
To unsubsc
ke" builds and
installs a driver module written with (more or less) the 2.4 API on any
kernel from 2.0 to 2.4, and the driver source is not full of ifdefs.
I suppose you're wondering where to get these files. Mail me and I'll
see if there's much demand.
cheers,
-- Jamie
-
T
Miquel van Smoorenburg wrote:
> .. but there should be a cleaner way to get at the CFLAGS used
> to compile the kernel.
There is a way though I'd not call it clean. Here is an extract from
the Makefile I am using for separately-distributed modules. It should
work with kernels 2.0 to 2.4, all su
the kernel's
reconfigured, a new file needs to be created. For 2.2 kernels it must
depend on whether SMP is defined too.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
#x27;re hard enough to do a cross compile,
you can build external modules using "make KERNEL_RELEASE=2.4.2
KERNEL_SOURCE=/home/jamie/cross_compiling/kernel ARCH=mips64" or
whatever.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
t; *
> * Nobody is assuming that. If you're hard enough to do a cross compile,
> * you can build external modules using "make KERNEL_RELEASE=2.4.2
> * KERNEL_SOURCE=/home/jamie/cross_compiling/kernel ARCH=mips64" or
> * whatever.
>
> Applications make that assumption
for module
packages to look there _unless_ you say otherwise.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
's no coincidence that I've had to write another very similar event
loop recently. You can see, this sort of thing is a real waste of CPU.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
ng X extensions for this working
Last time I looked at XF86DGA (years ago), it seemed to have the right
hooks in place. Just a matter of server implementation. My
recollection is dusty though.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
at's a 1990s problem that doesn't need a 2000s solution though :-)
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Daniel Phillips wrote:
> ls already can't handle the directories I'm working with on a regular
> basis. It's broken and needs to be fixed. A merge sort using log n
> temporary files is not hard to write.
ls -U | sort
should do the trick.
-- Jamie
-
To unsubscribe
a very complex thing, and
there are ways to optimise them for typical cases like the above.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
e vsync IRQs fine. E.g. TVGA
> 8900C.
Think of the original 64k and 256k VGA cards. I think some of those
didn't have an irq, but did have a way to read the progress of the
raster, which you could PLL to using timer interrupts. Some video games
still look fine at 320x200 :-)
-- Jamie
.
There's literature online about this class of problems: look up "event
set" and "simulation" and "fast priority queue".
enjoy,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
stream. This means that "memory" acts as a "compiler read
barrier".
> In short: I disagree 100%. A "memory" clobber -does- effectively tell the
> compiler that memory is read. If the compiler doesn't realize that, then
> it's a compiler bug wai
aches and so on. In theory the memory is reclaimed as required :-)
It's not a big issue with timers, as the timer elements are fixed size
structures that tend to be embedded in other structures. So the
lifetime of the timer element is the same as the lifetime of the object
associated with the ti
ransferred over the PCI bus).
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ble RED, I won't realise that I need to enable
traffic shaping first to discover the RED option.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
) removal.
You've just described the same as the current implementation, but with
lists for longer term timers. I.e. slower. With your coarser points,
you have to sort the front elements of the coarse list into a fine one
from time to time.
The idea of having jiffie-point pointers into a data
so perhaps this is not required?
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Daniel Phillips wrote:
> Jamie Lokier wrote:
> > Daniel Phillips wrote:
> > > ls already can't handle the directories I'm working with on a regular
> > > basis. It's broken and needs to be fixed. A merge sort using log n
> > > temporar
, or the Tyan in
particular? I've sent several reports of sudden system death on a VIA
motherboard, that were confirmed by a few other people. It's still
present in 2.2: Mandrake 7's installer froze, twice, until I added
"ide=nodma" (or whatever the option is). Note, this
george anzinger wrote:
> If we are to do high-res-timers, I think we will always have to do some
> sort of a sort on insert.
Yes, that's called a priority queue... (And you don't actually sort on
each insertion).
-- Jamie
-
To unsubscribe from this list: send the line "uns
imers are often removed before percolating down to the smallest tables.
It is possible to produce a general purpose heap which also has this
property.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ice's PCI configuration to have a 4k or
more sized window. (You said you were willing to move functionality
into the hardware, so I assume you can do this). That guarantees it
will be page aligned, and without other devices overlapping in
userspace.
-- Jamie
-
To unsubscribe from this list:
, but then you'd have to deal with memory allocation
failures and memory deadlocks, making add_timer rather complicated.
It's not acceptable for add_timer to fail or require kmalloc().
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
at has
> been discussed here has a O(log(n)) removal time.
Several priority queue structures support removal in O(1) time.
Perhaps you are thinking of the classic array-based heap, for
which removal is O(log n) in the general case.
-- Jamie
-
To unsubscribe from this list: send the line "
BIOS is making
the speaker beep), then syncing the disk, then maybe another pause, then
maybe some more disk activity, then finally shutting down. 2.3 started
the disk activity immediately and didn't pause. Perhaps 2.4.3 mm
problems?)
-- Jamie
-
To unsubscribe from this list: send the line
lt;;-)> all files should begin with a short
description of the contents of the file, 1 or 2 lines long. The
copyright notice comes next. Surely that's enough to identify an icon?
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
[Added Linus and linux-kernel as I think it's of general interest]
Kanoj Sarcar wrote:
> Whether Jamie was trying to illustrate a different problem, I am not
> sure.
Yes, I was talking about pte_test_and_clear_dirty in the earlier post.
> Look in mm/mprotect.c. Look at the
ic to one architecture. Do all SMP
CPUs support by Linux do the same thing on converting TLB entries from
clean to dirty, or do they have a subtle, easily missed data integrity
problem?
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
s?
I can vaguely imagine some COW optimisation where the pte is updated to
be writable with the new page's address, and there is no need to flush
other processor TLBs because they will do so when they first write to
the page. (But of course you have to be careful synchronising with
other u
interesting thought experiment though is this:
<< lock;
read pte
pte |= dirty
write pte
>> end lock;
if (!present(pte))
do_page_fault();
It would have a mighty odd effect wouldn't it?
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to want to make
> them bigger than necessary - so saving off the source address is
> unlikely.
Then again, these hypothetical addresses etc. aren't part of the
associative lookup, so could be located in something like an ordinary
cache ram, with just an index in the TLB itself.
-- Jamie
) is used by several garbage collectors, including threaded
ones. Maybe mprotect() isn't the best primitive for those anyway, but
it's what they have to work with atm.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
t; or "double scan"
schemes for mprotect() and it can stay as fast as possible.
Btw, a possible mprotect optimisation: there is no need for
flush_tlb_range() when increasing permissions.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
k (_PAGE_CHG_MASK, pte);
> atomic_set_mask (pgprot_val(newprot), *pte);
>
> for multi threaded apps.
cmpxchg is probably faster.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ult to test.
If anyone reports the message, _then_ we think about the problem some more.
Ben, fancy writing a boot-time test?
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
(don't call
> free_pages_ok() until flush_tlb_ipi returned). The difference is that we
> might have to perform a second pass to clear any spurious 0x40 bits.
That second pass is what I had in mind.
> * munmap(file): No. Second pass required for correct msync behaviour.
It is?
-- Jam
re and impossible to work around
processor bug has to do with this thread. It doesn't actually change
page fault handling, does it?
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
with write, change with lock;
> .
> .
> .
>
> But you'll never prove that you tested every combination.
Indeed.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.
, so such massive changes are out of question
> and your log n access argument is right.
A gigantic hash table has serious problems with non-locality of
reference. Basically any regular access pattern you started with is
destroyed. This is a problem with pageable RAM, let alone disks with
mi
(I hacked
getdents to return d_type).
d_type is quite effective for `find' type scans. I really ought to
release an updated treescan -- the intent was always to replace the
backend of `find' but I got caught up trying to optimise the order of
open/readdir/close sequences and then on to oth
hich
takes a list of files or standard input as argument:
#!/usr/bin/perl -pi
s/\r\n$/\n/
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.htm
Tim Waugh wrote:
> > Isn't `perl' overkill? Why not just:
> >
> > tr -d '\r'
>
> while read line; do echo ${line%?}; done
And those can be convert a set of files as "fromdos *.c" can they?
:-)
-- Jamie
-
To unsubscribe from this list
chooses the interpreter
based on filename :-)
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
cute
permission on the directory.
Also, you are getting notifications for unlinked files, which perhaps
you should not be able to know anything about. (If the directory wasn't
accessible when the file was unlinked for example, but was made
accessible later).
-- Jamie
-
To unsubscribe from this
1 - 100 of 498 matches
Mail list logo
