On Fri, 17 Aug 2007 11:56:11 +0800 Ian Kent <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-08-15 at 14:31 +0800, Ian Kent wrote:
> > On Tue, 2007-08-14 at 10:17 -0400, Jeff Moyer wrote:
> > > Ian Kent <[EMAIL PROTECTED]> writes:
> > > >
> > > > After spending quite a bit of time trying to resolve this
Matt,
It's not easy to do direct performance comparisons between pmaps and
pagemap/kpagemap. However some close analyzes are still possible :)
1) code size
pmaps ~200 LOC
pagemap/kpagemap~300 LOC
2) dataset size
take for example my running firefox on Intel Core 2:
VSZ
On Thu, 16 Aug 2007, Linus Torvalds wrote:
> On Fri, 17 Aug 2007, Paul Mackerras wrote:
> > I'm really surprised it's as much as a few K. I tried it on powerpc
> > and it only saved 40 bytes (10 instructions) for a G5 config.
>
> One of the things that "volatile" generally screws up is a simple
>
[ Cc: list heavily trimmed. ]
On Thu, 16 Aug 2007, Jeff Dike wrote:
> On Wed, Aug 15, 2007 at 05:40:11PM -0700, Joe Perches wrote:
> > fs/hostfs/hostfs_user.c:if(attrs->ia_valid & HOSTFS_ATTR_CTIME) ;
>
> This one can be deleted, but I think I did it for documentation
> reasons, to make
Rene Herman wrote:
> On 08/17/2007 03:58 AM, Alan Stern wrote:
>
>> On Fri, 17 Aug 2007, Rene Herman wrote:
>>
>>> On 08/16/2007 11:39 PM, Stefan Richter wrote:
Rene Herman wrote:
>
> I personally don't think there's a whole lot wrong with more and
> more expecting people who submit
Joe Perches wrote:
I've got a tree with a directory full of separate
MAINTAINER blocks that looks like:
00_file_description
3c359_network_driver
3c505_network_driver
3c59x_network_driver
3cr990_network_driver
...
zd1211rw_wireless_driver
zf_machz_watchdog
zr36067_video_for_linux_driver
zs_decsta
On Fri, Aug 17 2007, Neil Brown wrote:
> On Thursday August 16, [EMAIL PROTECTED] wrote:
> > On Thu, Aug 16 2007, NeilBrown wrote:
> > > Following are 5 patches which - I think - clean up various bits and pieces
> > > in the block layer.
> > >
> > > The only part that might be seen as a function c
David Griffith wrote:
> On Thu, 16 Aug 2007, Clemens Ladisch wrote:
> > Please try "amidi -d -p virtual" and playing a .mid file to this port with
> > aplaymidi.
>
> $ aplaymidi -p "virtual" castle2.mid
> Invalid port virtual - No such file or directory
Sorry, the name of the correspondig sequenc
Hi, Pavel,
On Thu, 2007-08-16 at 12:26 +0200, Pavel Machek wrote:
> Ping... is there some next version?
>
> I'm stuck at the tools side currently. kexec-1.101 just won't load the
> kernel properly, and kexec-testing from git does not know -j option. I
> tried hand-patching it, but got lots of sca
On Fri, 17 Aug 2007, Herbert Xu wrote:
> On Fri, Aug 17, 2007 at 01:43:27PM +1000, Paul Mackerras wrote:
> >
> > The cost of doing so seems to me to be well down in the noise - 44
> > bytes of extra kernel text on a ppc64 G5 config, and I don't believe
> > the extra few cycles for the occasional
This one-liner patch fixes a bug in drivers/auxdisplay/cfag12864b.c
At cfag12864b_init(), the driver tries to kalloc some memory in the
variable cfag12864b_cache.
Then, as usual, it checks if the call failed. However, it checks
cfag12864b_buffer instead.
This patch changes the "cfag12864b_buffer
Hi Linus,
[ and others; I think there's a communication gap in a lot of this
thread, and a little summary would be useful. Hence this posting. ]
On Thu, 16 Aug 2007, Linus Torvalds wrote:
> On Fri, 17 Aug 2007, Paul Mackerras wrote:
> >
> > I'm really surprised it's as much as a few K. I tr
Herbert Xu writes:
> On Fri, Aug 17, 2007 at 03:09:57PM +1000, Paul Mackerras wrote:
> > Herbert Xu writes:
> >
> > > Can you find an actual atomic_read code snippet there that is
> > > broken without the volatile modifier?
> >
> > There are some in arch-specific code, for example line 1073 of
>
On Fri, Aug 17, 2007 at 03:09:57PM +1000, Paul Mackerras wrote:
> Herbert Xu writes:
>
> > Can you find an actual atomic_read code snippet there that is
> > broken without the volatile modifier?
>
> There are some in arch-specific code, for example line 1073 of
> arch/mips/kernel/smtc.c. On mips
This patch fixes a bug of change_page_attr/change_page_attr_addr on
Intel x86_64 CPU. After changing page attribute to be executable with
these functions, the page remains un-executable on Intel x86_64
CPU. Because on Intel x86_64 CPU, only if the "NX" bits of all four
level page tables are cleared
On 8/17/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-08-17 at 06:37 +0200, Miguel Ojeda wrote:
> > On 8/16/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> > > On Thu, 2007-08-16 at 11:16 +0200, Miguel Ojeda wrote:
> > > > I think you could add also:
> > > > +F: Documentation/auxdispl
On Thu, Aug 16, 2007 at 08:42:23PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 17 Aug 2007, Paul Mackerras wrote:
> >
> > I'm really surprised it's as much as a few K. I tried it on powerpc
> > and it only saved 40 bytes (10 instructions) for a G5 config.
>
> One of the things that "volatile" g
Herbert Xu writes:
> Can you find an actual atomic_read code snippet there that is
> broken without the volatile modifier?
There are some in arch-specific code, for example line 1073 of
arch/mips/kernel/smtc.c. On mips, cpu_relax() is just barrier(), so
the empty loop body is ok provided that at
On Fri, Aug 17, 2007 at 09:28:00AM +0800, Herbert Xu wrote:
> On Thu, Aug 16, 2007 at 06:02:32PM -0700, Paul E. McKenney wrote:
> >
> > Yep. Or you can use atomic_dec_return() instead of using a barrier.
>
> Or you could use smp_mb__{before,after}_atomic_dec.
Yep. That would be an example of a
The overall approach looks fine to me, although I'm not the arbiter of
taste for the DMA API.
However, I think this wants to be split into at least three parts for
merging: adding the dmaflush flags stuff into the DMA API; adding the
dmaflush parameter to the ib_umem_get() API (and fixing every ca
Herbert Xu writes:
> So the point here is that if you don't mind getting a stale
> value from the CPU cache when doing an atomic_read, then
> surely you won't mind getting a stale value from the compiler
> "cache".
No, that particular argument is bogus, because there is a cache
coherency protocol
Add PCI IDs for the onchip UARTs on PA Semi PWRficient.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/serial/8250_pci.c
===
--- linux-2.6.orig/drivers/serial/8250_pci.c
+++ linux-2.6/drivers/serial/8250_
In message <[EMAIL PROTECTED]> you wrote:
> Michael Neuling wrote:
> >> I'd also request for you to add a cpu_scaled_run_real_total for use
> >> by delay accounting. cpu_scaled_run_real_total should be similar in
> >> functionality to cpu_run_real_total.
> >
> > Will do. Should I add cpu_scaled_r
--- Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > > I will write you a Perl script which will generate a complete
> > > and functionally equivalent SELinux policy (assuming I have enough
> > > free time) given a file with your policy language. But I can do this
> > > if and only if
On Fri, 2007-08-17 at 06:37 +0200, Miguel Ojeda wrote:
> On 8/16/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-08-16 at 11:16 +0200, Miguel Ojeda wrote:
> > > I think you could add also:
> > > +F: Documentation/auxdisplay/cfag12864bfb
> does not exist. I meant
>Documentation/
On Thu, 16 Aug 2007 21:24:22 PDT, Marc Perkel said:
> And then everything that's stored as /1/2/3/4 is still
> the same but the sections resolve to different names.
At that point, you need to go re-think your full-pathname permission scheme,
because that severely broke it.
> I'm sure there are er
Hi All,
Recently, I got a funny problem that my NFS client can't show some of
mounted directories. These directories that can't be showed by "ls"
command have great deals of files.
For example. I have a directory on NFS server log and there are 69
files. I can't show it's child files through
Michael Neuling wrote:
>> I'd also request for you to add a cpu_scaled_run_real_total for use
>> by delay accounting. cpu_scaled_run_real_total should be similar in
>> functionality to cpu_run_real_total.
>
> Will do. Should I add cpu_scaled_run_real_total to the end of the
> struct taskstat, or
Paul Mackerras wrote:
Nick Piggin writes:
Why are people making these undocumented and just plain false
assumptions about atomic_t?
Well, it has only been false since December 2006. Prior to that
atomics *were* volatile on all platforms.
Hmm, although I don't think it has ever been guara
Michael Neuling wrote:
>
> SLB shadow was bust. Make sure you have
> edd0622bd2e8f755c960827e15aa6908c3c5aa94
>
> [POWERPC] Fix potential duplicate entry in SLB shadow buffer
>
> We were getting a duplicate entry in the SLB shadow buffer in
> slb_flush_and_rebolt() if the kernel
On 8/16/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-16 at 11:16 +0200, Miguel Ojeda wrote:
> > I think you could add also:
> > +F: Documentation/auxdisplay/cfag12864bfb
>
> This is what I have now:
>
> CFAG12864BFB LCD FRAMEBUFFER DRIVER
> P: Miguel Ojeda Sandonis
> M:
On 08/16/2007 09:00 PM, Junio C Hamano wrote:
Git or no git, I think a file that can be viewed with less,
edited with regular editor and processed with sed/perl/grep
tools is the way to go. I do not think adding 600+ patches to
the single MAINTAINERS list is workable in the longer term, as
it w
On 8/16/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-16 at 11:16 +0200, Miguel Ojeda wrote:
> > I think you could add also:
> > +F: Documentation/auxdisplay/cfag12864bfb
>
> This is what I have now:
>
> CFAG12864BFB LCD FRAMEBUFFER DRIVER
> P: Miguel Ojeda Sandonis
> M:
Several people have asked about how to mass move a
tree under my idea for a new kind of file system. I
have an idea. Suppose you have the file name as
follies.
/one/two/three/four/file1
Except the are a million files in /four/ named file1
to file100.
We want to move thes files to /seven/six/
[ Your mailer drops Cc: lists, munges headers,
does all sorts of badness. Please fix that. ]
On Thu, 16 Aug 2007, David Schwartz wrote:
>
> > There is a quite convincing argument that such an access _is_ an
> > access to a volatile object; see GCC PR21568 comment #9. This
> > probably isn't
On Thu, 16 Aug 2007, Segher Boessenkool wrote:
> > Here, I should obviously admit that the semantics of *(volatile int *)&
> > aren't any neater or well-defined in the _language standard_ at all. The
> > standard does say (verbatim) "precisely what constitutes as access to
> > object of volatile
On Thu, 16 Aug 2007, Segher Boessenkool wrote:
> > Note that "volatile"
> > is a type-qualifier, not a type itself, so a cast of the _object_ itself
> > to a qualified-type i.e. (volatile int) would not make the access itself
> > volatile-qualified.
>
> There is no such thing as "volatile-quali
Nick Piggin writes:
> Why are people making these undocumented and just plain false
> assumptions about atomic_t?
Well, it has only been false since December 2006. Prior to that
atomics *were* volatile on all platforms.
> If they're using lockless code (ie.
> which they must be if using atomics
On Wed, 2007-08-15 at 14:31 +0800, Ian Kent wrote:
> On Tue, 2007-08-14 at 10:17 -0400, Jeff Moyer wrote:
> > Ian Kent <[EMAIL PROTECTED]> writes:
> > >
> > > After spending quite a bit of time trying to resolve this on more than
> > > one occassion, using rather complex and ulgy approaches, it tur
On Fri, Aug 17, 2007 at 11:44:37AM +0800, Fengguang Wu wrote:
> > I'm so-so on this.
>
> Not that way! It's a good thing that people have different experiences
> and hence viewpoints. Maybe the concept of PFN sharing are
> straightforward to you, while I have been playing with seq_file a lot.
>
On Fri, Aug 17, 2007 at 01:43:27PM +1000, Paul Mackerras wrote:
>
> The cost of doing so seems to me to be well down in the noise - 44
> bytes of extra kernel text on a ppc64 G5 config, and I don't believe
> the extra few cycles for the occasional extra load would be measurable
> (they should all h
On Fri, 17 Aug 2007, Nick Piggin wrote:
>
> I'm surprised too. Numbers were from the "...use asm() like the other
> atomic operations already do" thread. According to them,
>
> textdata bss dec hex filename
> 3434150 249176 176128 3859454 3ae3fe atomic_normal/vmlinux
> 3436
On Thu, Aug 16, 2007 at 09:38:46PM -0500, Matt Mackall wrote:
> On Fri, Aug 17, 2007 at 06:05:20AM +0800, Fengguang Wu wrote:
> > Show a process's page-by-page address space infomation in /proc//pmaps.
> > It helps to analyze applications' memory footprints in a comprehensive way.
> >
> > Pages sh
Linus Torvalds writes:
> In general, I'd *much* rather we used barriers. Anything that "depends" on
> volatile is pretty much set up to be buggy. But I'm certainly also willing
> to have that volatile inside "atomic_read/atomic_set()" if it avoids code
> that would otherwise break - ie if it hi
On Fri, 17 Aug 2007, Paul Mackerras wrote:
>
> I'm really surprised it's as much as a few K. I tried it on powerpc
> and it only saved 40 bytes (10 instructions) for a G5 config.
One of the things that "volatile" generally screws up is a simple
volatile int i;
i++;
which a c
Paul Mackerras wrote:
Nick Piggin writes:
So i386 and x86-64 don't have volatiles there, and it saves them a
few K of kernel text. What you need to justify is why it is a good
I'm really surprised it's as much as a few K. I tried it on powerpc
and it only saved 40 bytes (10 instructions) f
Nick Piggin writes:
> So i386 and x86-64 don't have volatiles there, and it saves them a
> few K of kernel text. What you need to justify is why it is a good
I'm really surprised it's as much as a few K. I tried it on powerpc
and it only saved 40 bytes (10 instructions) for a G5 config.
Paul.
-
Paul E. McKenney wrote:
On Thu, Aug 16, 2007 at 06:42:50PM +0800, Herbert Xu wrote:
In fact, volatile doesn't guarantee that the memory gets
read anyway. You might be reading some stale value out
of the cache. Granted this doesn't happen on x86 but
when you're coding for the kernel you can't
On Fri, 17 Aug 2007, Paul Mackerras wrote:
>
> Volatile doesn't mean it can't be reordered; volatile means the
> accesses can't be eliminated.
It also does limit re-ordering.
Of course, since *normal* accesses aren't necessarily limited wrt
re-ordering, the question then becomes one of "with
On Thu, Aug 16, 2007 at 09:16:17PM -0500, Matt Mackall wrote:
> On Fri, Aug 17, 2007 at 06:05:18AM +0800, Fengguang Wu wrote:
> > Split large vmas into page groups of proc_maps_private.batch_size bytes, and
> > iterate them one by one for seqfile->show. This allows us to export large
> > scale
> >
Christoph Lameter writes:
> No it does not have any volatile semantics. atomic_dec() can be reordered
> at will by the compiler within the current basic unit if you do not add a
> barrier.
Volatile doesn't mean it can't be reordered; volatile means the
accesses can't be eliminated.
Paul.
-
To
On Thu, Aug 16, 2007 at 09:13:47PM -0500, Matt Mackall wrote:
> On Fri, Aug 17, 2007 at 06:05:17AM +0800, Fengguang Wu wrote:
> > The "proportional set size" (PSS) of a process is the count of pages it has
> > in
> > memory, where each page is divided by the number of processes sharing it.
> > So
On Fri, Aug 17, 2007 at 06:05:20AM +0800, Fengguang Wu wrote:
> Show a process's page-by-page address space infomation in /proc//pmaps.
> It helps to analyze applications' memory footprints in a comprehensive way.
>
> Pages share the same states are grouped into a page range.
> For each page range
> Hi,
>
> My machine reboots automatically after a few seconds of booting 2.6.23-rc2-mm
2.
> I've tried several ways to debug the problem, but I've had no success.
> I am not sure if this problem has been reported already, a few simple searche
s
> did not indicate that the problem had been reporte
A new driver for the Broadcom BCM43xx devices has been written that uses mac80211, rather than
softmac. The newest versions of the Broadcom firmware does not support all the BCM devices.
Accordingly, a separate driver is being prepared that will use an older version of the firmware and
support t
Chris Snook wrote:
Herbert Xu wrote:
On Thu, Aug 16, 2007 at 03:48:54PM -0400, Chris Snook wrote:
Can you find an actual atomic_read code snippet there that is
broken without the volatile modifier?
A whole bunch of atomic_read uses will be broken without the volatile
modifier once we start
On Thu, 2007-08-16 at 19:13 -0700, Joe Perches wrote:
> Sorry, not a git developer, so the paths are wrong.
> This seems to work:
Sorry. Patch reversed too.
--- /usr/local/bin/git-send-email 2007-05-01 11:59:14.0 -0700
+++ /home/joe/bin/git-send-email.pl 2007-08-16 19:25:53.000
On 08/17/2007 03:58 AM, Alan Stern wrote:
On Fri, 17 Aug 2007, Rene Herman wrote:
On 08/16/2007 11:39 PM, Stefan Richter wrote:
Rene Herman wrote:
I personally don't think there's a whole lot wrong with more and
more expecting people who submit patches (for whom this automation
is intende
On Thu, 2007-08-16 at 14:56 -0400, Jeff Garzik wrote:
> Mike Frysinger wrote:
> > On 8/16/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >> Mike Frysinger wrote:
> >>> On 8/16/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Sonic Zhang wrote:
> > +static void bfin_set_piomode(struct ata_port *a
Segher Boessenkool wrote:
Part of the motivation here is to fix heisenbugs. If I knew where
they
By the same token we should probably disable optimisations
altogether since that too can create heisenbugs.
Almost everything is a tradeoff; and so is this. I don't
believe most people would f
On Fri, Aug 17, 2007 at 06:05:18AM +0800, Fengguang Wu wrote:
> Split large vmas into page groups of proc_maps_private.batch_size bytes, and
> iterate them one by one for seqfile->show. This allows us to export large
> scale
> process address space information via the seqfile interface. The old be
On Thu, Aug 16, 2007 at 10:04:24PM -0400, Chris Snook wrote:
>
> >Could you please cite the file/function names so we can
> >see whether removing the barrier makes sense?
>
> At a glance, several architectures' implementations of smp_call_function()
> have one or more legitimate atomic_read() bus
On Tue, 2007-08-14 at 18:31 -0700, Junio C Hamano wrote:
>On the other hand, git-send-email _is_ all about sending it
>out, and it needs to know who your patch should reach. I
>think it makes sense to have one script that, given a set of
>paths that are affected, gives a list of po
On Fri, Aug 17, 2007 at 06:05:17AM +0800, Fengguang Wu wrote:
> The "proportional set size" (PSS) of a process is the count of pages it has in
> memory, where each page is divided by the number of processes sharing it. So
> if
> a process has 1000 pages all to itself, and 1000 shared with one othe
Herbert Xu wrote:
On Thu, Aug 16, 2007 at 03:48:54PM -0400, Chris Snook wrote:
Can you find an actual atomic_read code snippet there that is
broken without the volatile modifier?
A whole bunch of atomic_read uses will be broken without the volatile
modifier once we start removing barriers that
On Fri, 17 Aug 2007, Rene Herman wrote:
> On 08/16/2007 11:39 PM, Stefan Richter wrote:
> > Rene Herman wrote:
>
> >> I personally don't think there's a whole lot wrong with more and more
> >> expecting people who submit patches (for whom this automation is
> >> intended) to be using git.
> >
>
On 08/16/2007 11:39 PM, Stefan Richter wrote:
Rene Herman wrote:
I personally don't think there's a whole lot wrong with more and more
expecting people who submit patches (for whom this automation is
intended) to be using git.
You mean "people who frequently submit patches for various differ
This patch removes the __STR() and STR() macros from x86_64 header files.
They seem to be legacy, and has no more users. Even if there were users,
they should use __stringify() instead.
In fact, there were one third place in which this macro was defined
(ia32_binfmt.c), and used just below. In thi
On Fri, 17 Aug 2007 01:14:50 +0900, Paul Mundt <[EMAIL PROTECTED]> wrote:
> > +MODULE_ALIAS("ds1742");
>
> Presumably this should be ds1553.
Oh of course! Thanks.
Subject: [PATCH] rtc: Make rtc-ds1553 driver hotplug-aware
Add an MODULE_ALIAS() to make this platform driver hotplug-aware.
Sign
On Thu, Aug 16, 2007 at 06:02:32PM -0700, Paul E. McKenney wrote:
>
> Yep. Or you can use atomic_dec_return() instead of using a barrier.
Or you could use smp_mb__{before,after}_atomic_dec.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
H
On Tue, Aug 14, 2007 at 04:41:16PM -0700, Paul E. McKenney wrote:
> Hello!
>
> Work in progress, not for inclusion.
>
> The attached patch passes multiple hours of rcutorture while hotplugging
> CPUs every ten seconds on 64-bit PPC and x86_64. It fails miserably on
> 32-bit i386 after a few hotp
On Thu, 2007-08-16 at 16:16 -0400, Dave Jones wrote:
> asides from the needed Kconfig clarification, is it necessary for khvcd
> to run at all if the lguest module hasn't been loaded ? Is it possible
> we can somehow delay creation of the kthread ?
It's for lguest guests, so it kind of needs to b
On Thu, 2007-08-16 at 16:11 +0200, Andi Kleen wrote:
> Huang, Ying wrote:
> > On Thu, 2007-08-16 at 06:42 +0800, Andrew Morton wrote:
> >> On Mon, 13 Aug 2007 15:30:19 +0800
> >> "Huang, Ying" <[EMAIL PROTECTED]> wrote:
> >>
> >>> Following sets of patches add EFI/UEFI (Unified Extensible Firmware
Alan Stern wrote:
> This patch (as960) removes the error message and stack dump logged by
> sysfs_remove_bin_file() when someone tries to remove a nonexistent
> file. The warning doesn't seem to be needed, since none of the other
> file-, symlink-, or directory-removal routines in sysfs complain i
This adds items to the taststats struct to account for user and system
time based on scaling the CPU frequency and instruction issue rates.
Adds account_(user|system)_time_scaled callbacks which architectures
can use to account for time using this mechanism.
Signed-off-by: Michael Neuling <[EMAIL
On Thu, Aug 16, 2007 at 01:20:26PM -0700, Christoph Lameter wrote:
> On Thu, 16 Aug 2007, Chris Snook wrote:
>
> > atomic_dec() already has volatile behavior everywhere, so this is
> > semantically
> > okay, but this code (and any like it) should be calling cpu_relax() each
> > iteration through
On Fri, Aug 17, 2007 at 07:59:02AM +0800, Herbert Xu wrote:
> On Thu, Aug 16, 2007 at 09:34:41AM -0700, Paul E. McKenney wrote:
> >
> > The compiler can also reorder non-volatile accesses. For an example
> > patch that cares about this, please see:
> >
> > http://lkml.org/lkml/2007/8/7/280
>
On Thu, Aug 16, 2007 at 05:10:25PM -0700, Shannon Nelson wrote:
> From: Adrian Bunk <[EMAIL PROTECTED]>
>
> This patch contains the following changes to the DMA engine menus:
>...
> - make it clear in the INTEL_IOATDMA help text that this driver is for
> rare hardware the user most likely doesn'
On Sun, Aug 05, 2007 at 11:00:29AM -0400, Theodore Tso wrote:
> P.S. Yet alternative is to specify noatime on an individual
> file/directory basis. We've had this capability for a *long* time,
> and if a distro were to set noatime for all files in certain
> hierarchies (i.e., /usr/include) a
Segher Boessenkool writes:
> Instead, use asm() like all other atomic operations already do.
> +static __inline__ long atomic64_read(const atomic_t *v)
> +static __inline__ void atomic64_set(atomic_t *v, long i)
s/atomic_t/atomic64_t/ in both lines. I've edited my copy of the patch.
Paul.
-
T
On Thursday August 16, [EMAIL PROTECTED] wrote:
> On Thu, Aug 16 2007, NeilBrown wrote:
> > Following are 5 patches which - I think - clean up various bits and pieces
> > in the block layer.
> >
> > The only part that might be seen as a function change rather than
> > simply rearranging code is in
In message <[EMAIL PROTECTED]> you wrote:
> Hi, Michael,
>
> Thanks for doing this, this is really useful.
>
> Michael Neuling wrote:
> > This adds two items to the taststats struct to account for user and
> > system time based on scaling the CPU frequency and instruction issue
> > rates.
> >
From: Adrian Bunk <[EMAIL PROTECTED]>
This patch contains the following changes to the DMA engine menus:
- switch to menuconfig
- INTEL_IOATDMA must depend on X86
- INTEL_IOATDMA must select DCA
- device drivers shouldn't "default m"
- DCA shouldn't be a user visible option
- make it clear in the
On Thu, Aug 16, 2007 at 03:23:49PM -0400, Chris Snook wrote:
>
> >You keep saying this yet everytime I ask for an example I
> >get nothing.
>
> Just look for all the code (and there's an immense amount) that has a
> barrier() between two atomic_* operations, or in a loop with such
> operations.
On Thu, Aug 16, 2007 at 03:48:54PM -0400, Chris Snook wrote:
>
> >Can you find an actual atomic_read code snippet there that is
> >broken without the volatile modifier?
>
> A whole bunch of atomic_read uses will be broken without the volatile
> modifier once we start removing barriers that aren't
On Thu, Aug 16, 2007 at 09:34:41AM -0700, Paul E. McKenney wrote:
>
> The compiler can also reorder non-volatile accesses. For an example
> patch that cares about this, please see:
>
> http://lkml.org/lkml/2007/8/7/280
>
> This patch uses an ORDERED_WRT_IRQ() in rcu_read_lock() and
> rcu_r
In message <[EMAIL PROTECTED]> you wrote:
> Michael Neuling wrote:
> > This adds POWERPC specific hooks for scaled time accounting.
> >
> > POWER6 includes a SPURR register. The SPURR is based off the PURR
> > register but is scaled based on CPU frequency and issue rates. This
> > gives a more
--- Milan Plzik <[EMAIL PROTECTED]> wrote:
> On Å t, 2007-08-09 at 16:06 +0100, Steven Newbury wrote:
> > --- Milan Plzik <[EMAIL PROTECTED]> wrote:
> >
> > > Good day,
> > >
> > > recently I've been trying to get working PCMCIA interface on H5000
> > > ipaq series, using dual PCMCIA sleeve
Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]>
---
include/linux/percpu_list.h |2 +-
include/linux/smp.h |3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
Index: dev/include/linux/percpu_list.h
===
--- dev.or
On Thu, Aug 16, 2007 at 03:57:24PM -0700, Linus Torvalds wrote:
> I personally consider this an affront to everythign that is decent.
>
> Why the *hell* would mkdir() be so magical as to need something like that?
>
> Make it something sane, like a "struct nameidata" instead, and make it at
> lea
On Aug 16, 2007, at 18:57:24, Linus Torvalds wrote:
On Wed, 15 Aug 2007, David Howells wrote:
Would you object greatly to functions like vfs_mkdir() gaining a
security parameter? What I'm thinking of is this:
int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode,
struct security *
Recent versions of the Linux kernel auto-suspend attached USB devices.
After this happens to the Canon EOS 5D camera, the camera's interrupt endpoints
don't seem to wake back up correctly, causing further use with libgphoto2
to fail with a -114 "OS error in camera communication" error.
A similar
On Friday 17 August 2007 01:06:47 Len Brown wrote:
> On Thursday 16 August 2007 15:36, Andi Kleen wrote:
> > > @@ -157,10 +162,13 @@ early_param("nosmp", nosmp);
> > > static int __init maxcpus(char *str)
> > > {
> > > get_option(&str, &max_cpus);
> > > - return 1;
> > > + if (max_cpus == 0)
>
On Aug 16, 2007, at 11:09:16, Phillip Susi wrote:
Kyle Moffett wrote:
Let me repeat myself here: Algorithmically you fundamentally
CANNOT implement inheritance-based ACLs without one of the
following (although if you have some other algorithm in mind, I'm
listening):
(A) Some kind of rec
Marc Perkel wrote:
> Yep - way outside the box - and thus the title of the
> thread.
>
> The idea is that people have permissions - not files.
> By people I mean users, groups, managers, applications
> etc. One might even specify that there are no
> permission restrictions at all. Part of the proc
On Thursday 16 August 2007 15:36, Andi Kleen wrote:
> > @@ -157,10 +162,13 @@ early_param("nosmp", nosmp);
> > static int __init maxcpus(char *str)
> > {
> > get_option(&str, &max_cpus);
> > - return 1;
> > + if (max_cpus == 0)
> > + disable_ioapic_setup();
>
> I must say I nev
On Wed, 15 Aug 2007, David Howells wrote:
>
> Would you object greatly to functions like vfs_mkdir() gaining a security
> parameter? What I'm thinking of is this:
>
> int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode,
> struct security *security)
I per
Altix supports "posted DMA", so that DMA may complete out
of order. In some cases it's necessary for a driver to
ensure that in-flight DMA has been flushed to memory for
correct operation.
In particular this can be a problem with Infiniband, where
writes to Completion Queues can race with DMA
> There is a quite convincing argument that such an access _is_ an
> access to a volatile object; see GCC PR21568 comment #9. This
> probably isn't the last word on the matter though...
I find this argument completely convincing and retract the contrary argument
that I've made many times in this
On Thu, 2007-08-16 at 17:58 +0200, Laurent Vivier wrote:
> [PATCH 3/3] introduce "account modifiers" mechanism in the kernel allowing a
> module to modify the collected accounting for a given task. This
> implementation
> is based on the "preempt_notifier". "account_system_time()" and
> "account_u
1 - 100 of 383 matches
Mail list logo
