Re: VM Requirement Document - v0.0
> Well, on a laptop memory and disk bandwith are rarely wasted - they cost > battery life. I've been playing around with different scenarios to see the differences in performance. A good way to trigger the cache problem is to untar a couple of kernel source trees or other large amounts of files, until free memory is down to less than 2mb. Then try to fire up a few apps that need some memory. The hard drive thrashes around as the VM tries to free up enough space, often using swap instead of flushing out the cache. These source trees can then be deleted which frees up the memory the cache was using and performance returns to where it should be. However, if I just fire up enough apps to use up all the memory and then go into swap, response is still acceptable. If the app requires loading from swap there is just a short lag while the VM does its thing and then life is good. I don't expect to be able to run more apps than I have memory for without a performance hit, but I do expect to be able to run with over 128MB of "real" free memory and not suffer from performance degradation (which doesn't happen at present) Mike - 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/
Re: VM Requirement Document - v0.0
> Remember that the first message was about a laptop. At 4:00AM there's > no activity but the updatedb one (and the other cron jobs). Simply, > there's no 'accessed-often' data. Moreover, I'd bet that 90% of the > metadata touched by updatedb won't be accessed at all in the future. > Laptop users don't do find /usr/share/terminfo/ so often. Maybe, but I would think that most laptops get switched off at night. Then when turned on again in the morning, anacron realizes it missed the nightly cron jobs and then runs everything. This really does make an incredible difference to the system. If I remove the updatedb job from cron.daily, the machine won't touch swap all day and runs like charm. (That's with vmware, mozilla, openoffice, all applications that like big chunks of memory) Mike - 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/
Re: VM Requirement Document - v0.0
> If individual pages could be classified as code (text segments), > data, file cache, and so on, I would specify costs to the paging > of such pages in or out. This way I can make the system perfer > to drop a file cache page that has not been accessed for five > minutes, over a program text page that has not been acccessed > for one hour (or much more). This would be extremely useful. My laptop has 256mb of ram, but every day it runs the updatedb for locate. This fills the memory with the file cache. Interactivity is then terrible, and swap is unnecessarily used. On the laptop all this hard drive thrashing is bad news for battery life (plus the fact that laptop hard drives are not the fastest around). I purposely do not run more applications than can comfortably fit in the 256mb of memory. If fact, to get interactivity back, I've got a small 10 liner that mallocs memory to *force* stuff into swap purely so I can have a large block of memory back for interactivity. Something simple that did "you haven't used this file for 30mins, flush it out of the cache would be sufficient" Mike - 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/
Re: LANANA: To Pending Device Number Registrants
> The same situation appears when using bonding.o. For several years, > Don Becker's (and derived) network drivers support changing MAC address > when the interface is down. So Al's /dev/eth//MAC has different values > depending on whether bonding is active or not. Should /dev/eth//MAC > always have the original value (to be able to uniquely identify this card) > or the in-use value (used by ARP, I believe) ? Or maybe have a > /dev/eth//MAC_in_use ? Token ring has the same problem as well, most token ring adapters support setting a LAA. Some solution would be useful though. Original mac sounds do-able. Mike - 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/
Re: skb->truesize > sk->rcvbuf == Dropped packets
> > > > Any suggestions on heuristics for this ? > > > > Not to set rcvbuf to ridiculously low values. The best variant is not > > to touch SO_*BUF options at all. > Hmmm... I don't see how not touching buffer values can solve his > problem at all. His MTU is really HUGE, and in this case 300 byte > packet eats 10k or so space in receive buffer. > I doubt our buffer size tuning algorithms can cope with this. Yep, it's no big thing to make the change in the driver, the copy is not that expensive and compared to the speed of the physical layer its virtually a non-impact. The most I've ever got out of 16 mbps t/r is just over 2 mb/second and memory copies can easily keep up with that. (That's with 8192 byte mtu's and ftp transfers which wouldn't get copied anyway). Mike - 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/
Re: skb->truesize > sk->rcvbuf == Dropped packets
>> I can implement one solution by copying the received packets into skb's >> with the correct length, but that eliminates the performance gains from >> simply swapping buffers around (and would definately mean no zero-copy). > Generally it is a win to copy rather than swap buffers when the frame does > not occupy most of the buffer. Most traffic is very small or MTU sized > frames (and on TR of course ethernet not TR mtu frames are popular) Any suggestions on heuristics for this ? Say maybe copy if skb->len <= eth_max_mtu, skb->len <= skb->truesize * .5, or just copy the packets no matter what size. Mike - 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/
skb->truesize > sk->rcvbuf == Dropped packets
Under certain conditions (e.g. nfs) the socket receive buffer is set to 2048, but in the dma token ring drivers we have the receive skb's set to mtu size, i.e. anything up to 18200. The default for these drivers is 4096. So, when any packets are received, even though the skb->len is less than sk->rcvbuf, these packets are getting dropping in sock_queue_rcv_skb causing massive timeout problems with nfs. I can implement one solution by copying the received packets into skb's with the correct length, but that eliminates the performance gains from simply swapping buffers around (and would definately mean no zero-copy). Is there a better way to do this, or can any changes be made in the socket handling functions ? Mike - 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/
Re: isa_read/write not available on ppc - solution suggestions ??
> We can certainly do that, no problem. > BUT that won't get a token ring pcmcia card working in the newer > powerbooks, such as the titanium G4 powerbook, because the PCI host > bridge doesn't map any cpu addresses to the bottom 16MB of PCI memory > space. This is not a problem as far as pcmcia cards are concerned - > the pcmcia stuff just picks an appropriate address (typically in the > range 0x9000 - 0x9fff) and sets the pcmcia/cardbus bridge to > map that to the card. But it means that the physical addresses for > the card's memory space will be above the 16MB point, so it is > essential to do the ioremap. This is where the multiple support issue comes in. In ibmtr_cs.c we do ioremap the addresses so pcmcia all works nicely. What we don't do at present is an ioremap in ibmtr.c for the non-pcmcia adapters (isa & mca). So, I suppose the real fix would be to implement the ioremap in ibmtr.c so that regular read/writes can be used everywhere in the driver. (This is half the battle with changes to the driver, it supports so many combinations that one change for one type of adapter can kill support for another adapter, and that's my bottom line with updates: No loss of functionality we already had.) Or we could just tell people to use the cardbus token ring adapter on ppc instead ;) Mike - 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/
Re: isa_read/write not available on ppc - solution suggestions ??
> I would suggest the opposite approach instead: make the PPC just > support isa_readx/isa_writex instead. > > Much simpler, and doesn't need changes to (correct) driver sources. > > I bet that the patch will be smaller too. It's a simple case of > - do the ioremap() _once_ at bootup, save the result in a static > variable somewhere. > - implement the (one-liner) isa_readx/isa_writex functions. > > On many architectures you don't even need to do the ioremap, as it's > always available (same as on x86). That would be my preferred solution as well. The one-liners are easy, the ioremap may be more fun. Time to investigate the ppc code and docs. Unless one of the kindly ppc maintainers who knows far more about the arch than me would like to do it :) Mike - 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/
Re: isa_read/write not available on ppc - solution suggestions ??
>[EMAIL PROTECTED] wrote: >> >> To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the >> isa_read/write's have to be changed to regular read/write due to the lack >> of the isa_read/write functions for ppc. > Treat it like a PCI device and use ioremap(). Then change isa_readl() > to readl() etc. Bleurgh, the latest version of the driver (not in the kernel yet) searches for turbo based cards by checking the isa address space from 0xc - 0xe in 8k chunks. So we'd have to ioremap each 8k section, check it, find out the adapter isn't there and then iounmap it. Oh well, if that's what it takes =:0 Mike - 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/
isa_read/write not available on ppc - solution suggestions ??
To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the isa_read/write's have to be changed to regular read/write due to the lack of the isa_read/write functions for ppc. So, the question is should I simply: a) change everything to read/write and friends (the way the driver used to be before the isa_read/write function were introduced) b) Put ugly macros in the driver to use the different functions depending upon architecture. c) Implement the isa_read/write functions for ppc ? or d) something completely different I haven't thought of. Remember, this driver must support isa, pcmcia, mca, ix86 and now ppc. Personally I'd rather not have arch dependent macros in the driver, but I know there is a good reason why the isa_read/write functions were introduced in the first place. Suggestions ? Mike Linux Token Ring Project http://www.linuxtr.net - 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/
Re: [PATCH] Updated Olympic Driver
Jeff, Thanks for the comments. This patch has been hanging too long already, the drivers should be updated as given and I'll work up all the fixes and another patch. >> + sisr=readl(olympic_mmio+SISR_RR) ; /* Read & Reset sisr */ > you should also check for 0x, which will happen if the hardware > disappears... We catch it in the Adapter Check and gracefully exit. >> struct olympic_tx_status olympic_tx_status_ring[OLYMPIC_TX_RING_SIZE]; > With PCI DMA you (theoretically) never pass any members of your private > struct directly to the chip. thus, either your comment or code is > wrong... On the cards to completely remove these structures from the private struct and allocate them in the driver. All other comments will be incorporated. Mike - 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/
[PATCH] Memory Leak fix for ibmtr
Here is a small patch that fixes a memory leak in the ibmtr driver.
Basically the bug occurs because the skb->tail pointer is set past the end
of the skb data buffer. This causes problems when the skb's are cloned
(they are unabled to be freed properly). The result is a leak that
eventually will stop the system.
Mike Phillips
Linux Token Ring Project
http://www.linuxtr.net
--- linux.orig/drivers/net/tokenring/ibmtr.cWed Feb 14 16:49:55 2001
+++ linux/drivers/net/tokenring/ibmtr.c Wed Feb 14 16:50:01 2001
@@ -1716,7 +1716,8 @@
}
#endif
- skb_size = length;
+ skb_size=(sizeof(struct trh_hdr)-lan_hdr_len+sizeof(struct
trllc)+15) & ~15;
+ skb_size+=length;
if (!(skb=dev_alloc_skb(skb_size))) {
DPRINTK("out of memory. frame dropped.\n");
@@ -1727,8 +1728,8 @@
return;
}
- skb_put(skb, length);
- skb_reserve(skb, sizeof(struct trh_hdr)-lan_hdr_len+sizeof(struct
trllc));
+ skb_reserve(skb, (sizeof(struct trh_hdr)-lan_hdr_len+sizeof(struct
trllc)+15) & ~15);
+ skb_put(skb,length);
skb->dev=dev;
data=skb->data;
rbuffer_len=ntohs(isa_readw(rbuffer + offsetof(struct rec_buf,
buf_len)));
-
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/
[PATCH] Cardbus support - Olympic Driver
Here is the small patch required to enable the olympic driver to work with
the olympic chipset based cardbus tokenring adapters.
The patch is against stock 2.4.2.
(Bigger fixes to enable proper hot-swap and pci api updates are in the
works)
Thanks
Mike Phillips
Linux Token Ring Project
http://www.linuxtr.net
diff -urN linux.orig/drivers/net/tokenring/olympic.c
linux.cb/drivers/net/tokenring/olympic.c
--- linux.orig/drivers/net/tokenring/olympic.c Sun Feb 25 14:19:14 2001
+++ linux.cb/drivers/net/tokenring/olympic.cSun Feb 25 14:19:43 2001
@@ -1,6 +1,6 @@
/*
* olympic.c (c) 1999 Peter De Schrijver All Rights Reserved
- *1999 Mike Phillips ([EMAIL PROTECTED])
+ *1999 Mike Phillips ([EMAIL PROTECTED])
*
* Linux driver for IBM PCI tokenring cards based on the
Pit/Pit-Phy/Olympic
* chipset.
@@ -38,10 +38,11 @@
*Fixing the hardware descriptors was another matter,
*because they weren't going through read[wl](), there all
*the results had to be in memory in le32 values. kdaaker
- *
+ * 12/23/00 - Added minimal Cardbus support (Thanks Donald).
*
* To Do:
- *
+ * Complete full Cardbus / hot-swap support.
+ *
* If Problems do Occur
* Most problems can be rectified by either closing and opening the
interface
* (ifconfig down and up) or rmmod and insmod'ing the driver (a bit
difficult
@@ -99,7 +100,7 @@
*/
static char *version =
-"Olympic.c v0.5.0 3/10/00 - Peter De Schrijver & Mike Phillips" ;
+"Olympic.c v0.5.C 12/23/00 - Peter De Schrijver & Mike Phillips" ;
static struct pci_device_id olympic_pci_tbl[] __initdata = {
{ PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_TR_WAKE, PCI_ANY_ID,
PCI_ANY_ID, },
@@ -191,10 +192,8 @@
if (pci_enable_device(pci_device))
continue;
- /* These lines are needed by the PowerPC, it
appears
-that these flags
-* are not being set properly for the PPC, this
may
-well be fixed with
+ /* These lines are needed by the PowerPC, it
appears that these flags
+* are not being set properly for the PPC, this
may well be fixed with
* the new PCI code */
pci_read_config_word(pci_device, PCI_COMMAND,
&pci_command);
pci_command |= PCI_COMMAND_IO |
PCI_COMMAND_MEMORY;
@@ -287,6 +286,10 @@
}
spin_lock_init(&olympic_priv->olympic_lock) ;
+
+/* Needed for cardbus */
+ if(!(readl(olympic_mmio+BCTL) & BCTL_MODE_INDICATOR))
+ writel(readl(olympic_priv->olympic_mmio+FERMASK)|FERMASK_INT_BIT,
olympic_mmio+FERMASK);
#if OLYMPIC_DEBUG
printk("BCTL: %x\n",readl(olympic_mmio+BCTL));
diff -urN linux.orig/drivers/net/tokenring/olympic.h
linux.cb/drivers/net/tokenring/olympic.h
--- linux.orig/drivers/net/tokenring/olympic.h Sun Feb 25 14:19:14 2001
+++ linux.cb/drivers/net/tokenring/olympic.hSun Feb 25 14:19:43 2001
@@ -1,6 +1,6 @@
/*
* olympic.h (c) 1999 Peter De Schrijver All Rights Reserved
- *1999 Mike Phillips ([EMAIL PROTECTED])
+ *1999 Mike Phillips ([EMAIL PROTECTED])
*
* Linux driver for IBM PCI tokenring cards based on the olympic and the
PIT/PHY chipset.
*
@@ -19,6 +19,7 @@
#define BCTL 0x70
#define BCTL_SOFTRESET (1<<15)
#define BCTL_MIMREB (1<<6)
+#define BCTL_MODE_INDICATOR (1<<5)
#define GPR 0x4a
#define GPR_OPTI_BF (1<<6)
@@ -124,6 +125,9 @@
#define TXSTATQCNT_2 0xe4
#define TXCSA_1 0xc8
#define TXCSA_2 0xe8
+/* Cardbus */
+#define FERMASK 0xf4
+#define FERMASK_INT_BIT (1<<15)
#define OLYMPIC_IO_SPACE 256
-
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/
