From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Wed, 29 Sep 2010 23:02:10 +0200 Subject: [U-Boot] [PATCH] lib/hashtable.c: add algorithm for small buffer import In-Reply-To: <8AE7E072-8389-49CA-B6C7-6C15C1877625@googlemail.com> References: <1285788486-43901-1-git-send-email-andreas.devel@googlemail.com> <20100929200131.DE00AD2B484@gemini.denx.de> <8AE7E072-8389-49CA-B6C7-6C15C1877625@googlemail.com> Message-ID: <20100929210210.BE6BCD2B484@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear =?iso-8859-1?Q?Andreas_Bie=DFmann?=, In message <8AE7E072-8389-49CA-B6C7-6C15C1877625@googlemail.com> you wrote: > > > With your configuration, importing a 64 kB environment buffer would > > result in 32 k entries in the hash table. > > Well therefore we have another 'algorithm' implemented to cope with > this. The flag H_ALG_SMALL_BUF should be set especially when importing a > small buffer. Anyhow the maximum limit some lines below will never be > exceeded. Well, you were talking about your defualt environment settings only. How big is the envrionment in your persistent storage (flash)? I bet it's at least several KB, resulting in thousands of entries in the hash table. > > This obviously makes no > > sense. > > > > I think we should rather make sure that a certain minimum of entries > > will always be available, for exmaple something like this: > > > > int nent = 64 + size / 8; > > This sounds also good but why do not calculate as before and after that > check some (maybe definable) borders? > > How about: > int nent = size / 8; > if (nent < CONFIG_ENV_MIN_ENTRIES) > nent = CONFIG_ENV_MIN_ENTRIES; I cannot really proof it, but I am pretty much convinced that we should start with a non-zero constant and rather use a less steep increase. > Well in most cases the environment needs a static size. The actual size > of environment has (in my view) no/small connection to space for > environment in NV memory. In most cases the space reserved for > environment is way to big cause of sector boundaries. Therefore I think This is not true. Sector sizes affect only the CONFIG_ENV_SECT_SIZE settings, while the environment size is determined by CONFIG_ENV_SIZE which usually is MUCH smaller. Example: "TQM5200.h": #define CONFIG_ENV_SIZE 0x4000 /* 16 k - keep small for fast booting */ ... #define CONFIG_ENV_SECT_SIZE 0x40000 > it would meet the needs when we have one (configurable) size for hash > table without the calculation. I disagree. Have a look at the "env import" and "env export" commands and think about what you can do with these - essentially they lift the fix connection to a pre-configured environment storage. Even if you have just 2 or 4 KiB environment settings in flash, you can now just load a file (over network, from USB stick or SDCard etc.) which may contain tons of commands and macro definitions. Even if you don't have such usage in mind, I do not want to make this impossible by a too limited design. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Too many people are ready to carry the stool when the piano needs to be moved.