headers
Steve French | 1 Jun 2007 01:08
Picon
Gravatar

[PATCH] support larger cifs network reads

With Samba 3.0.26pre it is now possible for a cifs client (one which
supports the newest Unix/Posix cifs extensions) to request up to
almost 8MB at a time on a cifs read request.

A patch for the cifs client to support larger reads follows.  In this
patch, using very large reads is not the default behavior, since it
would require larger buffer allocations for the large cifs request
buffers, but in the future when cifs can demultiplex reads to a page
list in the cifs_demultiplex_thread (without having to copy to a large
temporary buffer) this will be even more useful.

diff --git a/fs/cifs/README b/fs/cifs/README
index 4d01697..6ad722b 100644
--- a/fs/cifs/README
+++ b/fs/cifs/README
 <at>  <at>  -301,8 +301,19  <at>  <at>  A partial list of the supported mount op
 		during the local client kernel build will be used.
 		If server does not support Unicode, this parameter is
 		unused.
-  rsize		default read size (usually 16K)
-  wsize		default write size (usually 16K, 32K is often better over GigE)
+  rsize		default read size (usually 16K). The client currently
+		can not use rsize larger than CIFSMaxBufSize. CIFSMaxBufSize
+		defaults to 16K and may be changed (from 8K to the maximum
+		kmalloc size allowed by your kernel) at module install time
+		for cifs.ko. Setting CIFSMaxBufSize to a very large value
+		will cause cifs to use more memory and may reduce performance
+		in some cases.  To use rsize greater than 127K (the original
+		cifs protocol maximum) also requires that the server support
+		a new Unix Capability flag (for very large read) which some
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Hughes | 1 Jun 2007 01:09
Picon

Re: Add INPUT support to toshiba_acpi

On Thu, 2007-05-31 at 18:46 +0200, Andreas Mohr wrote:
> HCI_EMPTY is *by far* the most frequent state to occur I think
> (users won't press keys all the time), thus it's probably better(?)
> for branch prediction to have this placed first, right?
> Not that it matters too much instruction-wise, but still...

Sure.

> Apart from that I'm very happy to see progress on this front
> (speaking as a "proud" owner of an old Toshiba notebook requiring
> this stuff).

Good - this stuff should just work :-)

> And I'd definitely move the multiple identical "Re-enabled hotkeys" parts
> into one single non-inlined(!) function for the same reason.
> Not to mention that it's BUTT UGLY to have the *same* fat
> multi-line comment duplicated bazillion times.

Agree. New patch (untested) attached.

Thanks for review,

Richard.
Attachment (toshiba_acpi_add_buttons_05.patch): text/x-patch, 8 KiB
Permalink | Reply | 0 comments |
headers
Björn Steinbrink | 1 Jun 2007 01:09
Picon
Picon

Re: [BUG] Something goes wrong with timer statistics.

On 2007.06.01 00:59:11 +0200, Ian Kumlien wrote:
> On tor, 2007-05-31 at 17:27 +0200, Björn Steinbrink wrote:
> > On 2007.05.31 17:10:07 +0200, Eric Dumazet wrote:
> > > Well... :) , there is still a memory barrier missing it seems.
> > > 
> > > Another cpu might see a bad value if 'active=1' is set before tstat_hash_table is really cleared.
> > 
> > Hm, that even makes the assumption in my first try valid ;-)
> > Just for the record, this time I thought that the barrier from the
> > spinlock in timer_stats_update_stats (right before the check for active)
> > would be enough, but that's obviously running on the wrong cpu if we
> > race... *sigh*
> > 
> 
> Fix the comment below and you can add:
> Signed-off-by: Ian Kumlien <pomac <at> vapor.com>
> 
> It's currently been running for the longest period ever, ie, 11 minutes
> =)

Finally! :-)

> I'm gonna leave it running during the night and send a status update
> when the evil daystar reaches it's peak CET. (i haven't been able to
> stop since linus mentioned it... damn it... =))
> 
> >  <at>  <at>  -360,6 +364,7  <at>  <at>  static ssize_t tstats_write(struct file *file, const char __user *buf,
> >  		if (!active) {
> >  			reset_entries();
> >  			time_start = ktime_get();
(Continue reading)

Permalink | Reply | 1 comment |
headers
Linus Torvalds | 1 Jun 2007 01:12
Gravatar

Re: [2/4] 2.6.22-rc3: known regressions


On Thu, 31 May 2007, Andrew Morton wrote:
> 
> The status is "sitting in my queue for 2.6.22".  I'll be sending it up
> today or tomorrow.  Was hoping to get an ack from Greg &/| Andi on it, but
> those are not easy to come by.

Well, it looks "Obviously Correct(tm)", since clearly the iounmap() should 
be done _after_ the last use. So I don't think it needs any more acking.

But tomorrow is fine..

		Linus
Permalink | Reply | 2 comments |
headers
Mark Fasheh | 1 Jun 2007 01:13
Picon
Favicon

Re: 2.6.22-rc3-mm1 - page_mkwrite() breakage

On Wed, May 30, 2007 at 11:58:23PM -0700, Andrew Morton wrote:
>  git-ocfs2.patch

Andrew, thanks for getting that back in there.

mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch broke ocfs2 shared
writable mmap. We hang on a page lock because ->page_mkwrite() is
being called with the page already locked:

+	/*
+	 * For consistency in subsequent calls, make the nopage_page always
+	 * locked.
+	 */
+	if (unlikely(!(vma->vm_flags & VM_CAN_INVALIDATE)))
+		lock_page(nopage_page);

It wasn't previously being called with the page lock held, intentionally.
	--Mark

--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh <at> oracle.com
Permalink | Reply | 11 comments |
headers
Roland Dreier | 1 Jun 2007 01:17
Picon
Favicon

Re: [2/4] 2.6.22-rc3: known regressions

What about the changes to fix the order that MSI-X irqs are returned
in (iirc, list_add had to be changed to list_add_tail in a couple of
places).  Without that change, multiple MSI-X interrupts seem to be
broken: the kernel programs the MSI-X table in the opposite order that
it gives the irq numbers to the driver.  The net effect is that if I
request, say, 3 MSI-X interrupts for a device, then when the device
generates the first interrupt, the driver thinks it generated the
third interrupt, and things go fairly haywire.

 - R.
Permalink | Reply | 1 comment |
headers
Andrew Morton | 1 Jun 2007 01:20

Re: [PATCH] Introduce O_CLOEXEC (take >2)

On Thu, 31 May 2007 14:09:15 -0400
Ulrich Drepper <drepper <at> redhat.com> wrote:

> I've brought this topic up before but didn't provide a patch.  Well, here
> we go again, this time with a patch.  I even throw in a test program.
> 
> The problem is as follows: in multi-threaded code (or more correctly: all
> code using clone() with CLONE_FILES) we have a race when exec'ing.
> 
>    thread #1                       thread #2
> 
>    fd=open()
> 
>                                    fork + exec
> 
>   fcntl(fd,F_SETFD,FD_CLOEXEC)
> 
> In some applications this can happen frequently.  Take a web browser.  One
> thread opens a file and another thread starts, say, an external PDF viewer.
> The result can even be a security issue if that open file descriptor refers
> to a sensitive file and the external program can somehow be tricked into
> using that descriptor.
> 
> Just adding O_CLOEXEC support to open() doesn't solve the whole set of
> problems.  There are other ways to create file descriptors (socket,
> epoll_create, Unix domain socket transfer, etc).  These can and should
> be addressed separately though.  open() is such an easy case that it makes
> not much sense putting the fix off.
> 
> ...
(Continue reading)

Permalink | Reply | 8 comments |
headers
hermann pitton | 1 Jun 2007 01:23
Picon
Favicon

Re: dst customization patchset

Am Freitag, den 01.06.2007, 00:03 +0200 schrieb Markus Rechberger:
> On 5/31/07, Uwe Bugla <uwe.bugla <at> gmx.de> wrote:
> > Am Donnerstag, 31. Mai 2007 07:01 schrieb Bill Eldridge:
> > > timecop wrote:
> > > >>  Guys, it's GPL code. Fork the project and stop your bitching.
> > > >>  If you do a better job, people will use and contribute to your
> > version.
> > > >>  If you do a worse job, people will use and contribute to Manu's.
> > > >>  Some will use and contribute to both. Life's good, eh?
> > > >
> > > > This is exactly why Linux is shit.
> > > > You have 100s of "forked projects" because some guy named Uwe thought
> > > > he could do better than some guy named Manu and now you have two
> > > > projects to contribute to, both suck in various ways, of course some
> > > > idiot is going to be "backporting" from one to another, introducing
> > > > weird bugs, etc etc etc.
> > > >
> > > > Make a fucking decision and stick with it. Stop wasting everyone's
> > > > time. It's no secret that current Linux-DVB/V4L/whatever system is a
> > > > pile of steaming feces. Every one of you admitted to it on this list
> > > > at some point in the past. So get to it, make a fucking decision,
> > > > "fire" (loool) retards who are slowing the project down, and get shit
> > > > moving. I vote for Uwe as Linux-DVB maintainer.
> > > > Regards,
> > > > tc
> > >
> > > I nominate Timecop to be maintainer/top cop to figure out which version
> > > sucks in which area
> > > and do his best to get the best approach used. Sometimes a good strong
> > > and outspoken
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Miller | 1 Jun 2007 01:26
Favicon

Re: [PATCH] improved locking performance in rt_run_flush()

From: Herbert Xu <herbert <at> gondor.apana.org.au>
Date: Sun, 20 May 2007 15:11:48 +1000

> David Miller <davem <at> davemloft.net> wrote:
> > From: Dave Johnson <djohnson+linux-kernel <at> sw.starentnetworks.com>
> >> 
> >> The below patch changes rt_run_flush() to only take each spinlock
> >> protecting the rt_hash_table once instead of taking a spinlock for
> >> every hash table bucket (and ending up taking the same small set 
> >> of locks over and over).
> 
> ...
> 
> > I'm not ignoring it I'm just trying to brainstorm whether there
> > is a better way to resolve this inefficiency. :-)
> 
> The main problem I see with this is having to walk and free each
> chain with the lock held.  We could avoid this if we had a pointer
> in struct rtable to chain them up for freeing later.
> 
> I just checked and struct rtable is 236 bytes long on 32-bit but
> the slab cache pads it to 256 bytes so we've got some free space.
> I suspect 64-bit should be similar.

SLUB I believe packs more aggressively and won't pad things out like
that.  Therefore adding a member to rtable is much less attractive.

I've been considering various alternative ways to deal with this.

For 2.6.22 and -stable's sake we could allocate an array of pointers
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Garzik | 1 Jun 2007 01:26
Favicon

Re: Compact Flash performance...

Mark Lord wrote:
> To maximize throughput, some kind of host-queuing would be needed,
> or just have the driver sit in a tight loop, starting the next I/O
> immediately when the previous one finishes.  Linux isn't that quick (yet).

I was talking on IRC with Tejun just recently.  There are several 
controllers (and/or "situations") like this, where some amount of host 
queueing would permit greater throughput, even when NCQ is not 
supported.  sata_sx4 is the most dramatic example, where host queueing 
could potentially increase speed by a factor of 10 or more, since it is 
penalized by an awful two-irq-per-command (w/ a per-host bottleneck to 
boot) setup.  Silicon Image has a "command buffer".  And overall, I 
designed ->qc_prep() hook separate from ->qc_issue() to enable the 
prepartion of multiple commands such that it only takes a simple "go" 
I/O to start a transaction, immediately after the previous one ends.

	Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane