Originally Posted By: Ross Wellington
When a block of the current song is loaded, does any of it get loaded into a disk partition or does it go directly to the RAM for caching?

The player software loads it into a malloc'd buffer in RAM. Which means that the Linux kernel reads it into the page-cache (RAM), and them copies it to another location in RAM specified by the player software. Note to software developers: use mmap() instead of read() to avoid the memcpy and 2X memory requirement!!

Quote:
Is this a PIO transfer or DMA?

PIO. The empeg hardware completely lacks any provision for DMA from any device.

Quote:
1) Will increasing the player RAM help expand the cache or is the cache a fixed size and the RAM would only expand the program space for 3rd party programs, display data, etc?

2) If the RAM was expanded for cache would its performance be compromised due to a larger cache-flush requiring more time to do it? Will the break be more frequenct or a longer pause?

Since PIO is used (100% CPU during disk reads), and since the player software actively fights the Linux kernel's automatic caching, the result will be no different. Things will be jittery, possibly with a playback gap, while software is filling RAM with pre-read tracks. Since the RAM is larger, it will take longer to fill it. Where expanded RAM is useful, is in holding the larger data structures that come with large drives -- the filesystem metadata, and the empeg player's database.

Quote:
3) Is the cache 4 way set associative? If not, would that help the performance for the problem I mentioned above?

Dunno to the first question, and not likely to the second. X-way set associative memory caches only help with data that's already in RAM. The problem in the empeg is that there's not much RAM, and the data is on disk to begin with.

Quote:
4) Does the player use the on-disk drive cache?

The player is unaware of it, and the drive automatically uses it.

Quote:
Can it be utilized for cache queuing (sort of like L1, L2 cache so to speak)? Would that improve the performance if it was used?

Already happening. You already see the results.

Quote:
Is there a reference that defines the function of the partitions?

I think it's probably somewhere in the empeg FAQ.

Quote:
By expanding the partition sizes as you mentioned above, how would that improve performance?

Not. But a large drive is more likely (than a small drive) to have large numbers of tracks, possibly exceeding the design limits of the player software. One such group of limits has to do with the maximum number of FIDs ("tracks") in the current running order (or in a bookmark list), and how well this playlist is remembered across power cycles.

The memory for the current running order (and bookmarks) is actually the dynamic data partition on disk. Making this partition larger, in conjunction with some software changes (eg. a modified version of the set_empeg_max_fid hack), could alleviate those particular limits.

* * *

EDIT: A somewhat related discussion came up on the Linux Kernel Mailing List (LKML) last week. I had raised some issues there regarding the 2TB drives that are soon to hit the market, and the ensuing discussion eventually touched upon the same immediate issue that you have experienced: memory requirements for filesystem checks (fsck).

Ted (Tso) suggested that, for a 2TB filesystem, the machine might need as much as 2GB of memory for fsck to be guaranteed to run without crashing..

Cheers


Edited by mlord (06/04/2008 01:04)