headers
Andrew Morton | 1 May 2004 01:34

Re: [PATCH 2.6.6-rc3-mm1] Add maxthinktime to sysfs

FabF <Fabian.Frederick <at> skynet.be> wrote:
>
>        I notice huge variations in first seconds of a 10 client
>  throughput activity as attached (5,100,300 as maxthinktime).
>  It's just another parameter I'd like to play with ;)

Fair enough.  Interesting result.

Can you describe and/or publish ffbench?
Permalink | Reply | 0 comments |
headers
Junfeng Yang | 1 May 2004 01:40
Picon
Favicon

[CHECKER] Kernel panic when diWrite fails to get a page


txCommit calls diWrite, which can fail (diWrite -> read_metapage ->
read_cache_page).  txAbortCommit will be called in that case.  Kernel will
panic in LogSyncRelease on assert(log) because the "lo"g fields for some
metapages are NULL.  If we are going to kernel panic anyway, we should
panic at the first place without doing all these works to abort a
transcation.

int diWrite(tid_t tid, struct inode *ip)
{
	...
      retry:
	mp = read_metapage(ipimap, pageno << sbi->l2nbperpage, PSIZE, 1);
	if (mp == 0)
Fail -->	return -EIO;
	...
}

static void txAbortCommit(struct commit * cd)
{
	...
			if (mp->xflag & COMMIT_PAGE)
-->				LogSgyncRelease(mp);
	...
}

static void LogSyncRelease(struct metapage * mp)
{
	struct jfs_log *log = mp->log;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jose R. Santos | 1 May 2004 01:42
Picon
Favicon

Re: [PATCH] dentry and inode cache hash algorithm performance changes.

On 04/30/04 17:02:56, Andrew Morton wrote:
> Does this mean you need to redo the instrumentation and benchmarking?  If
> so, please do that and send the numbers along?  There's no particular
> urgency on that, but we should do it.

No, the screw up was made we I created the patch on a clean source
tree.  This patch represents the actual data gather on those graphs.

> Also, I'd be interested in understanding what the input to the hashing
> functions looked like in this testing.  It could be that the new hash just
> happens to work well with one particular test's dataset.  Please convince
> us otherwise ;)

hehehe...  I knew it could't be that easy. :)

For the dentry hash function, some of my other coorkers had put this
hash function through various testing and have concluded that the 
hash function was equal or better than the default hash function.
These runs were done with a (hopefully to be Open Source soon)
benchmark called FFSB which can simulate various io patters across
many filesystems and variable file sizes.

SpecSFS fileset is basically a lot of small file which varies 
depending on the size of the run.  For a not so big SMP system
the number of file is in the +20 Million files range.  Of those
20 million files only 10% are access randomly by the client.  The 
purpose of this is that the benchmark tries to stress not only
the NFS layer but, VM and Filesystems layers as well.  The filesets
are also hundreds of gigabytes in size in order to promote disk 
head movement by guaranteeing cache misses in memory.  SFS 27% of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Herbert Poetzl | 1 May 2004 01:43
Picon

Re: [ckrm-tech] Re: [RFC] Revised CKRM release

On Fri, Apr 30, 2004 at 06:17:39PM -0400, Jeff Dike wrote:
> nagar <at> watson.ibm.com said:
> > Jeff, do you have any numbers for UML overhead in 2.6 ? 
> 
> It obviously depends on the workload, but for "normal" things, like kernel
> builds and web serving, it's generally in the 20-30% range.  That can be 
> reduced, since I haven't spent too much time on tuning.  I'm aiming for the
> teens, and I don't think that'll be too hard.

hmm, just wanted to mention that linux-vserver has
around 0% overhead and often allows to improve 
performance due to resource sharing ... 

basically it's a soft partitioning concept based on 
'Security Contexts' which allow to create many 
independant Virtual Private Servers (VPS), which
act simultaneously on one box at full speed, sharing
the available hardware resources.

see http://linux-vserver.org for details ...

best,
Herbert

PS: UML and Linux-VServer play together nicely ...

> 
> 				Jeff
> 
> -------------------------------------------------------
(Continue reading)

Permalink | Reply | 3 comments |
headers
Lev Makhlis | 1 May 2004 02:09

Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATE 2

> +	for (fp = 0xF0000; fp < 0xFFFFF; fp += 16) {
> +		isa_memcpy_fromio(table_eps, fp, sizeof(*table_eps));
> +		if (memcmp(table_eps->anchor, "_SM_", 4)!=0)
> +			continue;

This is fine for x86 and x86_64, but for ia64 -- don't you need
to get the SMBIOS entry point from the EFI table?
Permalink | Reply | 3 comments |
headers
Nigel Cunningham | 1 May 2004 02:03

Re: [PATCH] Hotplug for device power state changes

Hi.

Sorry for getting in on this conversion a little late; I've only just  
noticed it.

The usual way in which userspace notification of suspending/resuming is  
handled at the moment is via scripts which are run prior to suspending and  
after resuming. As has been noted, the first thing the kernel side  
implementations does is freeze userspace, keeping things static until post  
resume. This seems to me to be a good, simple model. DHCP releases can be  
handled from user space, prior to echo 4 > /proc/acpi/sleep (or  
alternatives) and the whole difficulty regarding interactions between  
userspace and kernelspace just goes away.

Note too that the actual invocation of a suspend can still be in response  
to kernel events. An ACPI event can be sent to the userspace ACPI daemon,  
which does userspace preparations and then invokes the kernel suspend  
mechanism. After resume, it can also do userspace reinitialisation.

Given this model, I would suggest that hotplug should silently drop any  
events that happen while suspending, and queue events that occur while  
resuming until the kernelspace part of resuming is complete and userspace  
can run as normal. It shouldn't rely upon device suspend/resume  
notifications because they can and do happen while we're still in the  
process of suspending and resuming. The means to detect whether we're  
suspending or resuming or running normally could be implemented as a  
simple function that could test the status of the different suspend  
implementations.

Is that at all helpful?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jorge Bernal | 1 May 2004 02:40
Favicon

Re: [PATCH] Blacklist binary-only modules lying about their license

On Fri, Apr 30, 2004 at 04:11:29PM -0400, Marc Boucher wrote:
> 
> The purpose of the workaround is not to circumvent any protection, but 
> to fix a real usability issue for systems in the field, which, as an 
> expert you perhaps do not see, but users definitely massively felt and 
> complained about.
> 

You have argued this a lot of times during this thread and I want to say
smoenthing about that. I have used some binary-only modules: nvidia,
vmware and some time ago HSF drivers. When I installed the nvidia
propetary driver was the first time I saw the word 'tainted' and it
makes sense: I was at the console.

I mean that most of users work on X (except when installing X drivers
:)) and probably they will never see this "confusing" warnings.

When my system boots, it loads the nvidia and vmware modules and most of
time (I could say always) I don't notice that my kernel is tainted
(though I know) so I don't see the reason to hide the license.

I think it should be good for all to stop flaming and put some things in
order. You have lied about the license and it seems you want to keep
lying so -quoting Linus- it seems you don't have shame.

Cheers,
	Koke

--

-- 
"Sólo el éxito diferencia al genio del loco"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Todd Poynor | 1 May 2004 03:16

Re: [PATCH] Hotplug for device power state changes

Greg KH wrote:
> On Fri, Apr 30, 2004 at 12:59:40PM -0700, Todd Poynor wrote:
> 
>>* Changes to kobject to allow kobject hotplug to optionally be 
>>synchronous if desired.  I'd assume this is a new hotplug_ops field.
> 
> 
> Ick.

Is the objection to using kobject for synchronous hotplug events, or to 
using a hotplug_ops flag to indicate which kind is needed?  Would the 
addition of a kobject_hotplug_sync function be better?  Or a 
handshake-like interface as with firmware downloads?

>>* Synchronous hotplug events for system suspend and resume (without 
>>individual device notifications).  These events can probably be 
>>generated by the kobject hotplug methods by the existing power subsys 
>>(once the above enhancement is in place).
> 
> 
> But why?  Do you really need this?  Have you actually tested a system to
> see if it is needed?

This is something that was requested of me by others who build Linux 
into consumer electronics devices.  Perhaps some of the interested 
parties may speak up here to add more insight.  Among the intended uses 
that I'm aware of are: saving application state to stable storage (for 
example, to be prepared in case the battery dies during an extended 
"suspended" period, and such gadgets often do not have a device suitable 
for a complete system suspend-to-disk), terminating applications that
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg KH | 1 May 2004 03:48
Gravatar

Re: [PATCH] Hotplug for device power state changes

On Fri, Apr 30, 2004 at 06:16:22PM -0700, Todd Poynor wrote:
> Greg KH wrote:
> >On Fri, Apr 30, 2004 at 12:59:40PM -0700, Todd Poynor wrote:
> >
> >>* Changes to kobject to allow kobject hotplug to optionally be 
> >>synchronous if desired.  I'd assume this is a new hotplug_ops field.
> >
> >
> >Ick.
> 
> Is the objection to using kobject for synchronous hotplug events, or to 
> using a hotplug_ops flag to indicate which kind is needed?  Would the 
> addition of a kobject_hotplug_sync function be better?  Or a 
> handshake-like interface as with firmware downloads?

To add an option to the kobject_hotplug() function for a sync call is
one thing.  To make the option for the main kobject add and remove call
to be sync is a horribly misguided thought (the reason why is left as an
exercise for the reader...like go read the udev code for many reasons
why...)

I don't have an objection to add such a new paramater (or even a new
function call like you suggested), just don't go messing with the main
kobject hotplug call without thinking everything through :)

> >>* Synchronous hotplug events for system suspend and resume (without 
> >>individual device notifications).  These events can probably be 
> >>generated by the kobject hotplug methods by the existing power subsys 
> >>(once the above enhancement is in place).
> >
(Continue reading)

Permalink | Reply | 0 comments |

Gmane