* Re: blame now knows -S
From: Marco Costalba @ 2006-04-08 13:53 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Junio C Hamano, Martin Langhoff, git
In-Reply-To: <20060408114240.GA10137@c165.ib.student.liu.se>
On 4/8/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> On Fri, Apr 07, 2006 at 02:28:40AM -0700, Junio C Hamano wrote:
> > I've made a few changes to "git blame" myself:
> >
> > - fix breakage caused by recent revision walker reorganization;
> > - use built-in xdiff instead of spawning GNU diff;
> > - implement -S <ancestry-file> like annotate does.
> >
> > Depending on the density of changes, it now appears that blame
> > is 10%-30% faster than annotate. I thought CVS emulator might
> > be interested to give it a whirl..
> >
>
> Nice work!
>
> There is another possible optimisation with respect to xdiff. Instead
> of producing the diff on the xdiff side and parsing the diff in
> blame.c, we could add another call back which just gets the relevant
> information from the hunk header. I don't know how much we would gain
> from this, but it might be worth a try.
>
If I can comment on this thread, I would like to note IMHO that given
the differences in
languages (C vs Perl) and the use of almost the same algorithm, just a
10%-30% in speed difference between blame and annotate it means that
any further optimization can gain little because the bottleneck is
elsewhere.
And I think is in getting the revision's history. Call it
git-rev-list, although both
blame and annotate use directly the library revision.h
After the new xdiff merge, git-rev-list accounts for almost whole the time.
Normally more then 80% in qgit.
Although the qgit annotation algorithm is different from both blame
and annotate I think
that a faster git-rev-list <path> or revison history walker as you may
want to call it it's a key
in really speed-up annotation stuff.
Marco
^ permalink raw reply
* [lm-sensors] nForce 430 SMBus
From: Mark Rages @ 2006-04-08 13:53 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <74ee72ca0604071607l1c1063b2iad93659df1bfe3fa@mail.gmail.com>
Ok, here it is.
On 4/8/06, Rudolf Marek <r.marek at sh.cvut.cz> wrote:
>
> >
> > What do I need to do?
>
> Hello, please provide the dsdt.bin file:
> cat /proc/acpi/dsdt >dsdt.bin
>
> Send it to me and CC to list.
>
> Thanks,
> Regards
> Rudolf
>
--
You think that it is a secret, but it never has been one.
- fortune cookie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dsdt.bin
Type: application/octet-stream
Size: 21970 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060408/2ec3107a/dsdt-0001.bin
^ permalink raw reply
* Re: [PATCH] Fix compilation of 2.6.16-rt13 real-time preemption patch on PowerPC
From: Ingo Molnar @ 2006-04-08 13:50 UTC (permalink / raw)
To: Walter L. Wimer III; +Cc: linux-kernel, Gleixner, Thomas
In-Reply-To: <1144436297.10765.52.camel@excalibur.timesys.com>
* Walter L. Wimer III <walt.wimer@timesys.com> wrote:
> The following patch corrects errors encountered when compiling the
> 2.6.16-rt13 real-time preemption patch on the PowerPC architecture:
>
> * The INIT_FS and INIT_FILES macro definitions changed, but
> corresponding changes to the calls were missed on PowerPC.
>
> * The new TIF_NEED_RESCHED_DELAYED definition caused an overflow
> of a 16-bit immediate load field in several PowerPC
> assembly-language instructions (e.g. in entry.S). This patch
> changes the definition of TIF_NEED_RESCHED_DELAYED from the
> value 16 to the value 13 (which appears to have been previously
> unused). (All bits from 0 to 15 are now in use on PPC, so if
> any new thread_info flags are needed, we'll have to actually fix
> the PPC assembly code to deal with the resulting 32-bit
> quantity.)
>
> * The file include/asm-powerpc/irqflags.h was missing completely
> on PowerPC. For now, I've supplied a stub file. There is
> currently no support for CONFIG_DEBUG_TRACE_IRQFLAGS.
>
> Thanks go to Thomas Gleixner for his comments/suggestions on this
> patch.
>
> I've successfully built and test-booted this on an AMCC440EP "Bamboo"
> board.
thanks, applied.
Ingo
^ permalink raw reply
* [Qemu-devel] [PATCH] SPARC target : Fix carry flag update in addxcc and subxcc ops
From: Even Rouault @ 2006-04-08 13:46 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 270 bytes --]
I send a patch that should fix a bug in the update of carry flag for addxcc
and subxcc instructions when the carry flag is set before the evaluation of
the instruction.
(the fix is identical to what is done in the similar instruction
op_adcl_T0_T1_cc for arm target)
[-- Attachment #2: qemu-sparc-carry-xcc-ops.patch --]
[-- Type: text/x-diff, Size: 2130 bytes --]
? patch-qemu-sparc-xcc_ops.txt
Index: op.c
===================================================================
RCS file: /sources/qemu/qemu/target-sparc/op.c,v
retrieving revision 1.18
diff -u -p -r1.18 op.c
--- op.c 30 Oct 2005 17:28:50 -0000 1.18
+++ op.c 7 Apr 2006 22:04:40 -0000
@@ -415,9 +415,9 @@ void OPPROTO op_addx_T1_T0(void)
void OPPROTO op_addx_T1_T0_cc(void)
{
target_ulong src1;
-
+ target_ulong has_carry = FLAG_SET(PSR_CARRY);
src1 = T0;
- T0 += T1 + FLAG_SET(PSR_CARRY);
+ T0 += T1 + has_carry;
env->psr = 0;
#ifdef TARGET_SPARC64
if (!(T0 & 0xffffffff))
@@ -435,7 +435,7 @@ void OPPROTO op_addx_T1_T0_cc(void)
env->xcc |= PSR_ZERO;
if ((int64_t) T0 < 0)
env->xcc |= PSR_NEG;
- if (T0 < src1)
+ if (T0 < src1 || (has_carry && T0 <= src1))
env->xcc |= PSR_CARRY;
if (((src1 ^ T1 ^ -1) & (src1 ^ T0)) & (1ULL << 63))
env->xcc |= PSR_OVF;
@@ -444,7 +444,7 @@ void OPPROTO op_addx_T1_T0_cc(void)
env->psr |= PSR_ZERO;
if ((int32_t) T0 < 0)
env->psr |= PSR_NEG;
- if (T0 < src1)
+ if (T0 < src1 || (has_carry && T0 <= src1))
env->psr |= PSR_CARRY;
if (((src1 ^ T1 ^ -1) & (src1 ^ T0)) & (1 << 31))
env->psr |= PSR_OVF;
@@ -505,9 +505,9 @@ void OPPROTO op_subx_T1_T0(void)
void OPPROTO op_subx_T1_T0_cc(void)
{
target_ulong src1;
-
+ target_ulong has_carry = FLAG_SET(PSR_CARRY);
src1 = T0;
- T0 -= T1 + FLAG_SET(PSR_CARRY);
+ T0 -= T1 + has_carry;
env->psr = 0;
#ifdef TARGET_SPARC64
if (!(T0 & 0xffffffff))
@@ -525,7 +525,7 @@ void OPPROTO op_subx_T1_T0_cc(void)
env->xcc |= PSR_ZERO;
if ((int64_t) T0 < 0)
env->xcc |= PSR_NEG;
- if (src1 < T1)
+ if (src1 < T1 || (has_carry && src1 <= T1))
env->xcc |= PSR_CARRY;
if (((src1 ^ T1) & (src1 ^ T0)) & (1ULL << 63))
env->xcc |= PSR_OVF;
@@ -534,7 +534,7 @@ void OPPROTO op_subx_T1_T0_cc(void)
env->psr |= PSR_ZERO;
if ((int32_t) T0 < 0)
env->psr |= PSR_NEG;
- if (src1 < T1)
+ if (src1 < T1 || (has_carry && src1 <= T1))
env->psr |= PSR_CARRY;
if (((src1 ^ T1) & (src1 ^ T0)) & (1 << 31))
env->psr |= PSR_OVF;
^ permalink raw reply
* Re: [RFC][PATCH 1/5] uts namespaces: Implement utsname namespaces
From: Andi Kleen @ 2006-04-08 13:45 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: linux-kernel
In-Reply-To: <20060407183600.C8A8F19B8FD@sergelap.hallyn.com>
"Serge E. Hallyn" <serue@us.ibm.com> writes:
> This patch defines the uts namespace and some manipulators.
> Adds the uts namespace to task_struct, and initializes a
> system-wide init namespace which will continue to be used when
> it makes sense.
So to get this straight - you want to add a new pointer to
task_struct for each possible virtualized entity?
After you're doing by how many bytes will task_struct be bloated?
I don't think that's a very good approach because you'll crank
up the per thread memory overhead which is already far too big
in Linux. Also it adds cache foot print and generally makes
things slower.
If anything I would request using a proxy data structure
that contains all the virtualized namespaces for a set
of processes. And give each task only has a single pointer
to one of these.
-Andi
^ permalink raw reply
* Re: [RFC][PATCH 1/5] uts namespaces: Implement utsname namespaces
From: Andi Kleen @ 2006-04-08 13:44 UTC (permalink / raw)
Cc: linux-kernel
In-Reply-To: <20060407183600.C8A8F19B8FD@sergelap.hallyn.com>
"Serge E. Hallyn" <serue@us.ibm.com> writes:
> This patch defines the uts namespace and some manipulators.
> Adds the uts namespace to task_struct, and initializes a
> system-wide init namespace which will continue to be used when
> it makes sense.
So to get this straight - you want to add a new pointer to
task_struct for each possible virtualized entity?
After you're doing by how many bytes will task_struct be bloated?
I don't think that's a very good approach because you'll crank
up the per thread memory overhead which is already far too big
in Linux. Also it adds cache foot print and generally makes
things slower.
If anything I would request using a proxy data structure
that contains all the virtualized namespaces for a set
of processes. And give each task only has a single pointer
to one of these.
-Andi
^ permalink raw reply
* Re: Black box flight recorder for Linux
From: Andi Kleen @ 2006-04-08 13:41 UTC (permalink / raw)
To: James Courtier-Dutton; +Cc: linux-kernel
In-Reply-To: <44379AB8.6050808@superbug.co.uk>
James Courtier-Dutton <James@superbug.co.uk> writes:
>
> Now, the question I have is, if I write values to RAM, do any of those
> values survive a reset?
They don't generally.
Some people used to write the oopses into video memory, but that
is not portable.
-Andi
^ permalink raw reply
* Re: [LARTC] u32 and iptables do not work together
From: Andreas Klauer @ 2006-04-08 13:37 UTC (permalink / raw)
To: lartc
In-Reply-To: <4436AEB8.1070300@cnett.com.br>
On Sat, Apr 08, 2006 at 03:18:01PM +0200, Piotr Chytla wrote:
> On Sat, Apr 08, 2006 at 08:21:40AM -0300, Nataniel Klug wrote:
> > I think it worked fine... This is my new script (below the text). I just
> > dont know how can I know if this traffic is relly going to the class I
> > send it... hehehehe... I am marking Skype packages using L7-Filter like
> > this:
> >
> If you want to see packets in class you can use sch_log, quite good
> module, you must attach it to class and you will see every packet
> in this class in tcpdump.
Or, without additional software, and a bit less of information,
you could just have a look at the tc statistics. In case of mixed
classes you can temporarily create an extra class for the packets
you want to test filters on.
If packets go into this class and it's the same number as are marked
by iptables, the classification works.
Regards
Andreas Klauer
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* [BUG] 2.6.16.2 (like olders) fails to suspend audio device
From: Patrizio Bassi @ 2006-04-08 13:31 UTC (permalink / raw)
To: Kernel,
I've already posted same bug some weeks ago.
this is just a reminder and to confirm bug is still there.
00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
Alsa driver: 1370
1) if builtin in kernel, on resume it doesn't work any more.
2) if built as module on resume it works with no need to remove/readd
module.
in both situations dmesg shows:
pnp: Failed to activate device 00:0b.
Stopping tasks: ===========================================|
Shrinking memory... done (39214 pages freed)
pnp: Device 00:0c disabled.
pnp: Device 00:08 disabled.
swsusp: Need to copy 13752 pages
ACPI: PCI Interrupt 0000:00:04.2[D] -> Link [LNKD] -> GSI 9 (level, low)
-> IRQ 9
ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 9 (level, low)
-> IRQ 9
ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 9 (level, low)
-> IRQ 9
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKC] -> GSI 5 (level, low)
-> IRQ 5
ACPI: PCI Interrupt 0000:00:0a.1[B] -> Link [LNKD] -> GSI 9 (level, low)
-> IRQ 9
ACPI: PCI Interrupt 0000:00:0a.2[C] -> Link [LNKA] -> GSI 11 (level,
low) -> IRQ 11
usb usb1: root hub lost power or was reset
ehci_hcd 0000:00:0a.2: USB 2.0 started, EHCI 0.95, driver 10 Dec 2004
ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKB] -> GSI 10 (level,
low) -> IRQ 10
pnp: Device 00:08 activated.
pnp: Failed to activate device 00:0b.
pnp: Device 00:0c activated.
Restarting tasks... done
agpgart: Found an AGP 1.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 2x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 2x mode
lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host
bridge (rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP
bridge (rev 03)
00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
(rev 74)
00:0a.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 50)
00:0a.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 50)
00:0a.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51)
00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF/SG AGP
dmesg says 00:08 and 00:0c are activated..but i've no idea which devices
they are, lspci -vv shows nothing about that.
Ready to give more infos and test patches.
Patrizio Bassi
^ permalink raw reply
* Re: [PATCH rc1-mm] de_thread: fix deadlockable process addition
From: Oleg Nesterov @ 2006-04-08 17:27 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <m1d5fslcwx.fsf@ebiederm.dsl.xmission.com>
On 04/08, Eric W. Biederman wrote:
>
> Agreed. That is ugly.
Yes, I agree also.
>
> -#define thread_group_leader(p) (p->pid == p->tgid)
> +#define thread_group_leader(p) (p == p->group_leader)
>
> ...
>
> - leader->group_leader = leader;
> + leader->group_leader = current;
I thought about similar change too, but I am unsure about
release_task(old_leader)->proc_flush_task() path (because
I don't understand this code).
This change can confuse next_tid(), but this is minor.
I don't see other problems.
However, I think we can do something better instead of
attach_pid(current)/detach_pid(leader):
void exec_pid(task_t *old, task_t * new, enum pid_type type)
{
new->pids[type].pid = old->pids[type].pid;
hlist_replace_rcu(&old->pids[type].node, &new->pids[type].node);
old->pids[type].pid = NULL;
}
So de_thread() can do
exec_pid(leader, current, PIDTYPE_PGID);
exec_pid(leader, current, PIDTYPE_SID);
This allows us to iterate over pgrp/session lockless without
seeing the same task twice, btw. But may be it is just unneeded
complication.
> This requires changing the leaders parents
>
> current->parent = current->real_parent = leader->real_parent;
> - leader->parent = leader->real_parent = child_reaper;
> + leader->parent = leader->real_parent = current;
> current->group_leader = current;
I don't understand why do we need this change.
Actually, I think leader doesn't need reparenting at all.
ptrace_unlink(leader) already restored leader->parent = ->real_parent
and ->sibling. So I think we can do (for review only, should go in a
separate patch) this:
--- MM/fs/exec.c~ 2006-04-08 02:19:15.000000000 +0400
+++ MM/fs/exec.c 2006-04-08 18:50:35.000000000 +0400
@@ -704,7 +704,6 @@ static int de_thread(struct task_struct
ptrace_unlink(current);
ptrace_unlink(leader);
remove_parent(current);
- remove_parent(leader);
/* Become a process group leader with the old leader's pid.
@@ -718,13 +717,11 @@ static int de_thread(struct task_struct
attach_pid(current, PIDTYPE_SID, current->signal->session);
list_replace_rcu(&leader->tasks, ¤t->tasks);
- current->parent = current->real_parent = leader->real_parent;
- leader->parent = leader->real_parent = child_reaper;
+ current->parent = current->real_parent = leader->parent;
current->group_leader = current;
leader->group_leader = leader;
add_parent(current);
- add_parent(leader);
if (ptrace) {
current->ptrace = ptrace;
__ptrace_link(current, parent);
Oleg.
^ permalink raw reply
* Re: script binding for reiserfs?
From: Danny Milosavljevic @ 2006-04-08 13:30 UTC (permalink / raw)
To: Dongxu Ma; +Cc: Peter van Hardenberg, reiserfs-list
In-Reply-To: <9bc0d5d20604072116j250b3d84m9f77c750d1f1d460@mail.gmail.com>
Hi,
Am Samstag, den 08.04.2006, 12:16 +0800 schrieb Dongxu Ma:
>
>
> On 4/8/06, Peter van Hardenberg <pvh@pvh.ca> wrote:
> Dongxu,
>
> Reaching into the filesystem itself for a project like this is
> not a very good idea. A wiki is a set of files -- let the
> filesystem do the hard work for you and use the standard API
> that is already in existence -- the VFS. You'll get all the
> benefits of the Reiser filesystem without having to break
> compatibility with other systems.
>
> my own thought is that one can operate the filesystem, or at least
> query it via programming interface, you know,
well, use the usual interface:
stat
creat
lockf
open
write
read
close
truncate
unlink
opendir
readdir
closedir
rename
sendfile
utime
readlink
I don't get what good it would do to use some extra interface with
different functions, given that all possible basic actions are already
covered... (although transactions would be nice to have ;))
> introduce shell is really a bad idea.
What do you mean by that?
>
> I think a DBI/DBD interface to a Reiser-friendly file format
> is a really neat idea. You could create table rows as
> individual files within a directory and do foreign keys with
> links!
You mean like in a relational database? That's very unflexible and a bad
idea on a filesystem. There is a reason relational databases are only
used properly in well-defined and limited-size big-design-up-front
projects.
And good relational databases are not even stored in files, but directly
onto the raw partition.
> I wonder what on-disk form would leverage Reiser4's dancing
> trees and intelligent allocation the most efficiently?
>
> Yeah, I can store each field into a file, and creat view and table
> structure from directory and links. With the help of reiserfs, I
> assume this could be possible to try.
It really depends on what you want to do with it, but of course you can
store each field into a file of it's own. The question is if you need
that kind of fine granularity...
>
cheers,
Danny
>
> I must say though, there is no binding to the Reiser4 API, and
> the Namesys team is very busy right now working towards
> getting R4 included in the mainline kernel. Hopefully once
> they have achieved this, the more exciting development can
> continue.
>
> 2.6.16 is a big step;-P
>
>
> As for your second question, my experience is strictly with
> R4, so someone else will have to comment on that issue.
>
> Anyway, great help for me, thanks.
>
>
> All the best,
> Peter van Hardenberg
>
>
> On 4/6/06, Dongxu Ma <dongxu.ma@gmail.com> wrote:
> Hi all,
>
> As reiserfs more and more popular, is there any
> binding package for use in script languages? I did a
> search on Google and nothing found.
> Curently I am thinking about writing a binding for
> Perl, which can offer:
> 1) script-level operation against reiserfs
> 2) DBI && DBD for reiserfs binding to treat the fs as
> a database. My aim is constructing a mid-and-small
> wiki directly on reiserfs without employing any real
> database
>
> However, after some seeking on source. I got several
> issues:
> 1) is there any so-called official userspace api
> exported?
> On gentoo there is a package named progsreiserfs
> introducing an api set under /usr/include/reiserfs,
> but I am not very sure if it is stable and the project
> is still alive.
>
> 2) regarding reiser3, where could I start to port?
> since exporting something in kernelspace is quite
> risky.
>
> Any advice and hint?
>
>
> --
> Cheers, Dongxu
> __END__
> dongxu.wordpress.com
> search.cpan.org/~dongxu
>
>
>
>
> --
> Peter van Hardenberg
> Victoria, BC, Canada
> "The wise man proportions his belief to the evidence." --
> David Hume
>
>
>
> --
> Cheers, Dongxu
> __END__
> dongxu.wordpress.com
> search.cpan.org/~dongxu
^ permalink raw reply
* Re: [LARTC] u32 and iptables do not work together
From: Piotr Chytla @ 2006-04-08 13:18 UTC (permalink / raw)
To: lartc
In-Reply-To: <4436AEB8.1070300@cnett.com.br>
On Sat, Apr 08, 2006 at 08:21:40AM -0300, Nataniel Klug wrote:
> I think it worked fine... This is my new script (below the text). I just
> dont know how can I know if this traffic is relly going to the class I
> send it... hehehehe... I am marking Skype packages using L7-Filter like
> this:
>
If you want to see packets in class you can use sch_log, quite good
module, you must attach it to class and you will see every packet
in this class in tcpdump.
http://kernel.umbrella.ro/net/sch_log/v0.4/sch_log-0.4.tar.gz
or Vincent Perrier's sch_spy (I don't have url).
/pch
--
Dyslexia bug unpatched since 1977 ...
exploit has been leaked to the underground.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [Qemu-devel] Translation cache sizes
From: Paul Brook @ 2006-04-08 13:16 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <200604080413.52908.jseward@acm.org>
On Saturday 08 April 2006 04:13, Julian Seward wrote:
> Using qemu from cvs simulating x86-softmmu (no kqemu) on x86,
> booting SuSE 9.1 and getting to the xdm (kdm?) graphical login
> screen, requires making about 1088000 translations, and the
> translation cache is flushed 17 times. Booting is not too bad,
> but once user-mode starts to run the translation cache is pretty
> much hammered.
>
> I made 2 changes:
>
> * increase CODE_GEN_BUFFER_SIZE from 16*1024*1024
> to 64*1024*1024,
>
> * observe that CODE_GEN_AVG_BLOCK_SIZE of 128
> for the softmmu case is too low; my measurements put it
> at about 247. So I changed it to 256.
>
> With those changes in place, the same boot-to-kdm process
> requires only about 570000 translations to be made, and 2
> cache flushes to happen. Of course the cost is an extra
> 48M of memory use.
Did you measure any actual speedup from these changes?
In a typical linux boot there's a lot of new code run only once, so I'd expect
the tb cache to be hammered fairly heavily.
Paul
^ permalink raw reply
* Re: [Qemu-devel] Translation cache sizes
From: Paul Brook @ 2006-04-08 13:10 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <3ACA6D63-C6FD-11DA-9D2F-003065C7D858@mandriva.com>
On Saturday 08 April 2006 13:43, Gwenole Beauchesne wrote:
> Hi,
>
> > With those changes in place, the same boot-to-kdm process
> > requires only about 570000 translations to be made, and 2
> > cache flushes to happen. Of course the cost is an extra
> > 48M of memory use.
>
> I faced a similar problem in Basilisk II. MacOS 8.x had a tendency to
> invalidate the code cache approx. 1000 times per second. My poor
> K6-2/300 was suffering a lot. About 45% of the time was dedicated to
> compilation of code, and desktop experience was very sluggish. Then, I
> came up with a very simple idea I named "lazy cache flush". Performance
> increased by 76% and compilation time dropped below 10%, desktop
> experience was very smooth. I will give you more contemporary results
> hereunder.
Qemu already does this. Initially it does it on a per-page basis (writes to a
given physical memory page will invalidate all code on that page), and for
frequently contested pages it does more fine-grained locking.
x86 doesn't have explicit icache invalidate instructions, the icache is
architecturally defined to be coherent after every jump instructions.
Paul
^ permalink raw reply
* Re: Regarding Wrapfs Code - function wrapfs_interpose
From: Avishay Traeger @ 2006-04-08 13:10 UTC (permalink / raw)
To: UZAIR LAKHANI; +Cc: linux-fsdevel
In-Reply-To: <20060408045146.59678.qmail@web37907.mail.mud.yahoo.com>
On Fri, 2006-04-07 at 21:51 -0700, UZAIR LAKHANI wrote:
> I want to find out the purpose of a part of Wrapfs
> code.
>
> The function name is wrapfs_interpose
>
> The code is
>
> /* check that the lower file system didn't cross a
> mount point */
> if (lower_inode->i_sb != SUPERBLOCK_TO_LOWER(sb)) {
> err = -EXDEV;
> goto out;
> }
>
> I want to find out what is the purpose of the above
> check.
Exactly what the comment says - it checks to make sure that we didn't
cross a mount point. It does this by making sure that the lower-level
superblock of this lower-level inode is the same as the lower-level
superblock that we expect (the one used at mount-time). So basically,
if we see a superblock that is different from the one we usually use, we
crossed a mount point and so we return an error.
Avishay Traeger
http://www.fsl.cs.sunysb.edu/~avishay/
^ permalink raw reply
* Re: Overhead of Using a Stackable File System(Wrapfs)
From: Avishay Traeger @ 2006-04-08 13:04 UTC (permalink / raw)
To: UZAIR LAKHANI; +Cc: linux-fsdevel
In-Reply-To: <20060408064833.9579.qmail@web37905.mail.mud.yahoo.com>
On Fri, 2006-04-07 at 23:48 -0700, UZAIR LAKHANI wrote:
> Thanks for replying but consider this scenario.
>
> What Wrapfs code do is this
>
> user_request ---> vfs_request ---> wrapfs_request --->
> actual_fs_request ---> storage
>
> Now consider this scenario in a network environment
>
> (client machine)
> user_request ---> vfs_request ---> wrapfs_request --->
>
> Network ---> (server machine)actual_fs_request --->
> storage
>
> The network here gets client requests and send them to
> server and vice versa.
The main benefit of stackable file systems is that you do not need to
duplicate the functionality found in lower-level file systems. In your
scenario, you do not use the lower-level file system at all, so you will
need to implement all the functionality of a lower-level file system,
plus deal with all the stackable file system code (which you will use
but won't need). Using wrapfs in this case will give you no benefit,
and will just make your life more difficult, and your code slower and
more difficult to read. I recommend you just start from scratch.
Avishay Traeger
http://www.fsl.cs.sunysb.edu/~avishay/
^ permalink raw reply
* [lm-sensors] nForce 430 SMBus
From: Rudolf Marek @ 2006-04-08 13:00 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <74ee72ca0604071607l1c1063b2iad93659df1bfe3fa@mail.gmail.com>
>
> What do I need to do?
Hello, please provide the dsdt.bin file:
cat /proc/acpi/dsdt >dsdt.bin
Send it to me and CC to list.
Thanks,
Regards
Rudolf
^ permalink raw reply
* first attempt at xen-3.0.2 & ocfs2
From: James Harper @ 2006-04-08 12:51 UTC (permalink / raw)
To: xen-devel
All my xen physical and virtual domains run off of AoE so a clustered
filesystem is a good thing for me!
Under Debian 'Etch', it almost 'just works'. First I installed
'ocfs2-tools' '1.1.5-2' + a patch from the Debian bug tracking system
(this is the 'almost' bit, it won't work without the patch)
Then I created a configuration and brought up the cluster on two nodes,
created a filesystem on a shared partition and mounted it. Then I added
another node. Almost too easy :)
Next I'll try it as a root filesystem which should really give it a
workout. Ocfs2 apparently supports a nifty feature where you can create
contextual symlinks which effectively means you can have the one
filesystem for all the nodes but also have node specific files.
James
^ permalink raw reply
* Re: Serial console problem with Xen 3.0
From: Michael Paesold @ 2006-04-08 12:44 UTC (permalink / raw)
To: Keir Fraser; +Cc: Don Zickus, xen-devel Devel, Jan Beulich
In-Reply-To: <41f19219621fc0c5bcf2815d863d14a7@cl.cam.ac.uk>
Keir Fraser wrote:
>
> On 7 Apr 2006, at 17:51, Keir Fraser wrote:
>
>>> I just wanted to confirm that pnpacpi=off solves my problem and give
>>> me full access over the serial console.
>>>
>>> Should this get an issue in the bugtracker?
>>
>> Yes, it's probably a good thing to gather all this stuff in one place.
>> By the way, I have some fixes already for the IO-APIC checking routine
>> that I mentioned. We're just going to give it a shakedown in Cambridge
>> before putting it in the public repository.
>
> I can confirm that my patch at least fixes the pnpacpi problem that
> you've been seeing. I've also enabled CONFIG_PNP_ACPI by default in our
> -xen0 and -xen defconfig files, so we should get wider feedback on
> issues relating to that config option now.
Great, I am going to pull from xen-unstable after the weekend and test the
changes.
Thanks to Don and Stephen for the "pnpacpi=off" hint.
Best Regards,
Michael Paesold
^ permalink raw reply
* [U-Boot-Users] Linux-Hangs
From: Ganesh Ramachandran @ 2006-04-08 12:43 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20060407102544.324E5352664@atlas.denx.de>
Thanks Denk.
I'm now trying with Non-XIP-Image. I am getting the Same.
1) I have a small doubt in ATAG. While passing the command line argument
through 'theKernel', where will be the control passed in the kernel. I mean
which function.
2) Is Control Register and ATAG both are same in Kernel? I couldn't find
ATAG in kernel comments i found only the Control Register.
Thanks & Regards,
Ganesh Ramachandran.
On 4/7/06, Wolfgang Denk <wd@denx.de> wrote:
>
> In message <21c86c970604070256i1e9a64c3u3d2d5bfbaa02eb29@mail.gmail.com>
> you wrote:
> >
> > ## Checking Image at 00007fc0 ...
> ^^^^^^^^
> > Image Name: Linux 2.6.16
> > Image Type: ARM Linux Kernel Image (uncompressed)
> > Data Size: 1152816 Bytes =3D 1.1 MB
> > Load Address: 00007fc0
> ^^^^^^^^
> ...
> > XIP Kernel Image ... OK
>
> Try booting a non-XIP-image first. I'm not sure about the state of
> support for XIP for ARM systems.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> HANDLE WITH EXTREME CARE: This Product Contains Minute Electrically
> Charged Particles Moving at Velocities in Excess of Five Hundred
> Million Miles Per Hour.
>
--
P. Ganesh Ramachandran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20060408/9f1dee03/attachment.htm
^ permalink raw reply
* Re: [Qemu-devel] Translation cache sizes
From: Gwenole Beauchesne @ 2006-04-08 12:43 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <200604080413.52908.jseward@acm.org>
Hi,
> With those changes in place, the same boot-to-kdm process
> requires only about 570000 translations to be made, and 2
> cache flushes to happen. Of course the cost is an extra
> 48M of memory use.
I faced a similar problem in Basilisk II. MacOS 8.x had a tendency to
invalidate the code cache approx. 1000 times per second. My poor
K6-2/300 was suffering a lot. About 45% of the time was dedicated to
compilation of code, and desktop experience was very sluggish. Then, I
came up with a very simple idea I named "lazy cache flush". Performance
increased by 76% and compilation time dropped below 10%, desktop
experience was very smooth. I will give you more contemporary results
hereunder.
So what's lazy invalidation of the translation cache? Well, the goal is
simple: keep translated code as long as possible. In practise, you
invalidate the complete translation cache only when it is full. Other
explicit cache invalidation (CINV instructions on 68k, icbi on ppc,
etc.) is virtual. This means the code is kept but it is put in a
"dormant" state. That is, usual entry points (in the hash table, or
inter-block jumps) are redirected to a check/recovery code where the
source block is checksumed again. If it matches original's the
previously compiled code is brought back to life (restoration of entry
points in hash table, and inter-block links). Otherwise, it's
recompiled and new code is used.
It's very simple and quite efficient. Since, I had no need to increase
the translation cache beyond 8MB.
So, here are a few results on an Athlon64 3200+. Translation cache is
set to 8MB. The test consisted in booting to MacOS 8, running all
Speedometer 4 tests, then shuting down the virtual Mac.
* Without lazy flush:
Number of soft flushes: 0
Number of hard flushes: 101387
Number of checksums : 0
Number of calls to compile_block : 20244047
Total emulation time : 115,8 sec
Total compilation time : 59,4 sec (51,3%)
* With lazy flush:
Number of soft flushes: 405520
Number of hard flushes: 7
Number of checksums : 46545721
Number of calls to compile_block : 340104
Total emulation time : 66,1 sec
Total compilation time : 1,8 sec (2,8%)
The results speak by themselves. ;-)
Speedometer 4 "Performance Rating" increased by 12%. More
interestingly, Color QuickDraw tests improved by a 12x factor: scored
19.95 on average with lazy cache flush, 1.67 without.
Bye,
Gwenolé.
^ permalink raw reply
* Re: Page Migration: Make do_swap_page redo the fault
From: Hugh Dickins @ 2006-04-08 12:16 UTC (permalink / raw)
To: Christoph Lameter; +Cc: akpm, linux-mm
In-Reply-To: <Pine.LNX.4.64.0604032228150.24182@schroedinger.engr.sgi.com>
On Mon, 3 Apr 2006, Christoph Lameter wrote:
> It is better to redo the complete fault if do_swap_page() finds
> that the page is not in PageSwapCache() because the page migration
> code may have replaced the swap pte already with a pte pointing
> to valid memory.
>
> do_swap_page may interpret an invalid swap entry without this patch
> because we do not reload the pte if we are looping back. The page
> migration code may already have reused the swap entry referenced by our
> local swp_entry.
Wouldn't you better just remove that !PageSwapCache "Page migration has
occured" block? Isn't that case already dealt with by the old !pte_same
check below it?
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [patch] ipv4: initialize arp_tbl rw lock
From: Sam Ravnborg @ 2006-04-08 12:14 UTC (permalink / raw)
To: David S. Miller
Cc: heiko.carstens, shemminger, jgarzik, akpm, netdev, linux-kernel,
fpavlic, davem
In-Reply-To: <20060408.031404.111884281.davem@davemloft.net>
On Sat, Apr 08, 2006 at 03:14:04AM -0700, David S. Miller wrote:
> Perhaps fs_initcall() would work better. Or if that causes
> problems we could create a net_initcall() that sits between
> fs_initcall() and device_initcall().
fs_initcall() seems to be used mainly for "init after subsystem" stuff.
Within fs/ only pipe.c uses fs_initcall().
If we are going to overload the usage of fs_initcall() even more then
we should maybe try to rename it?
Sam
^ permalink raw reply
* Dumpable tasks and ownership of /proc/*/fd
From: Petr Baudis @ 2006-04-08 12:08 UTC (permalink / raw)
To: linux-kernel
Hello,
I would like to ask why is /proc/*/fd owned by root when the task is
not dumpable - what security concern does it address? It would seem more
reasonable to me if the /proc/*/fd owner would be simply always the real
uid of the process.
The issue is that now all tasks calling setuid() from root to non-root
during their lifetime will not be able to access their /proc/self/fd.
This is troublesome because the fstatat() and other *at() routines are
emulated by accessing /proc/self/fd/*/path and that will break with
setuid()ing programs, leading to various weird consequences (e.g. with
the latest glibc, nftw() does not work with setuid()ing programs and
furthermore causes the LSB testsuite to fail because of this, etc.).
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: Fw: [Bugme-new] [Bug 6349] New: iptables DNAT returns unknown error 4294967295
From: Patrick McHardy @ 2006-04-08 11:58 UTC (permalink / raw)
To: dmb; +Cc: Andrew Morton, netdev, Netfilter Development Mailinglist
In-Reply-To: <4437A3B9.8000000@trash.net>
[-- Attachment #1: Type: text/plain, Size: 211 bytes --]
Patrick McHardy wrote:
> Please try if this patch helps.
>
> + .hooks = 1 << NF_IP_PRE_ROUTING || 1 << NF_IP_LOCAL_OUT,
I shouldn't send patches before getting out of bed .. :)
Please try this one instead.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 976 bytes --]
[NETFILTER]: Fix DNAT in LOCAL_OUT
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 2ceefa038e908d5da21aefedae02da4eab1b2787
tree 417f03eca3b97b16a78321ace1556e57f5c60351
parent 8cc24d7ca2ffc6d9d70e1d94dc8dffbdf677e58f
author Patrick McHardy <kaber@trash.net> Sat, 08 Apr 2006 13:59:53 +0200
committer Patrick McHardy <kaber@trash.net> Sat, 08 Apr 2006 13:59:53 +0200
net/ipv4/netfilter/ip_nat_rule.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/netfilter/ip_nat_rule.c b/net/ipv4/netfilter/ip_nat_rule.c
index efba8c4..1aba926 100644
--- a/net/ipv4/netfilter/ip_nat_rule.c
+++ b/net/ipv4/netfilter/ip_nat_rule.c
@@ -279,7 +279,7 @@ static struct ipt_target ipt_dnat_reg =
.target = ipt_dnat_target,
.targetsize = sizeof(struct ip_nat_multi_range_compat),
.table = "nat",
- .hooks = 1 << NF_IP_PRE_ROUTING,
+ .hooks = (1 << NF_IP_PRE_ROUTING) | (1 << NF_IP_LOCAL_OUT),
.checkentry = ipt_dnat_checkentry,
};
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.